首页 文章 精选 留言 我的

精选列表

搜索[移动解析],共10009篇文章
优秀的个人博客,低调大师

PaaS架构解析

一、PaaS的发展简史 PaaS作为新一代的云计算平台,目前在业界得到了广泛的关注与讨论。诸多大公司也纷纷推出自己的PaaS平台,比如Pivotal的CloudFoundry, IBM的Bluemix和Redhat的OpenShift等。其实在此之前, PaaS已经有很长一段时间的发展历程。在2007年,Salesforce最早发布force.com,其目的是支持第三方客户在Salesforce.com上开发和部署定制软件,它基本使用的元数据驱动的方式来开发和管理应用。在2008年4月的时候,技术巨头Google发布GAE(Google AppEngine),其目的是争夺独立开发者和创业公司的市场。GAE在发布之时就得到了业界的广泛关注,在很多方面都突破了原有的技术思路,比如使用容器来部署应用,简化的用户体验等。但是,我们也看到,GAE在业务上并没有获得巨大的成功,后面的发展也证明AWS的策略更加成功。一年之后,新浪SAE也发布,其命名、发展思路与架构模式和GAE非常类似,当然,业务上也同样不太成功。 AWS也看到了PaaS平台的潜力,与2011年发布其官方PaaS平台Beanstalk。在Beanstalk之前,几乎所有的PaaS平台都是基于Linux容器技术LXC。AWS提供了另外一种打造PaaS平台的思路,即基于虚拟机完成应用的自动部署和运维,同时Beanstalk也提供了自动弹性伸缩的功能。容器和虚拟机主要是在资源利用率、安全性和隔离性上有所差别。 CloudFoundry是另外一个里程碑式的PaaS产品,在推出之日就吸引了诸多的焦点,甚至带动了PaaS搜索关键字在Google趋势里面搜索量的飚升。CloudFoundry的成功有这样几个原因:首先它是开源的和免费的。开放源代码意味着全球所有的开发者都能非常简单的部署自己的PaaS平台,同时也意味着让所有的开发者看到打造一个PaaS平台需要哪些关键的技术;其次,CloudFoundry是开放的,它能够支持多种编程语言和开发框架,也能够提供多种服务类型,虽然CloudFoundry的架构经过了几次重构,但是开放性这个关键的特性一直都保留;第三,CloudFoundry提供了一个极简的用户体验,开发人员只需要简单的几个命令就能部署自己的应用系统,彻底颠覆了之前的用户体验。当然,这种用户体验最早是来自于Heroku。 最后值得一提的是大热的Docker。Linux容器技术已经出现了很多很多年,在各大互联网巨头公司也使用了很多很多年,但是Docker利用AUFS技术第一次将容器实例镜像化,这一突破性的创新能够让容器实例可复制、可迁移、可重用。该思路彻底打破了以前只有使用虚拟机才能迁移实例的局限,所以迅速在业界得到追捧。Docker的东家DotCloud甚至把自己的PaaS平台卖掉以专心发展该项技术。 目前来看,PaaS平台技术还处于群雄逐鹿的状态,诸多技术巨头都在不遗余力的发展自己的PaaS平台以跟上技术发展的脚步。以此同时,独立的PaaS提供商(如Heroku、AppFog)等也纷纷被技术巨头收购,这带来了一种质疑的声音是PaaS是否真的能够成为一项独立可持续发展的业务模式。下文将会对此做一些简单的探讨。 二、PaaS架构比较 大致来看,PaaS的实现分为两种:以虚拟机为基础或是以容器为基础。前者的代表是AWS,后者的代表则是GAE, CloudFoundry和Heroku。前文已经提到,AWS是基于虚拟机技术来打造自己的PaaS平台,其架构模式大致如下图所示: 具体而言,AWS基于如下构件打造了Beanstalk:首先是负载均衡层(ELB),该层需要将用户的请求投射到对应的服务器实例,同时,负载均衡层还需要。当应用实例出现扩容时,需要动态将调整的服务器实例注册到对应的域名上,以完成分流;中间是Web服务器层,目前ElasticBean支持Java、Python和PHP等多种编程语言,尽量为编程人员提供多样性的选择,开放性基本是所有PaaS平台的标配。在服务后端,Beanstalk基本依托于AWS本身的服务生态系统为应用提供服务,比如RDS、S3、DynamoDB等。 CloudFoundry等平台则是基于容器技术打造。相比于虚拟机,容器带来的系统开销非常低,如果一台虚拟机的操作系统需要占用2G的内存,则7个虚拟机所组成的集群只是操作系统就需要14G的内存占用。基于容器的技术如果一台16G的裸机除去2G的操作系统开销,还能够部署7个容器进程。所以,从经济性来说,容器的技术远远好于虚拟机。另外一个比较的标准是性能,容器的性能相对而言更好一些,具体的比较参数可以参见IBM研究院刚刚出的报告【1】。但是,从安全性和隔离型来说,虚拟机是远远好于容器的。 CloudFoundry的架构设计如下图所示。首先,CF也提供了一个路由模块(Router),该模块基本是基于ngnix打造,只是在ngnix技术上提供了动态注册的功能。在部署时,由于CF会同时部署非常多的应用实例,所以需要一个router集群来满足应用的需要;其次,CF的应用容器基于自己开发的warden技术,warden也是基于LXC技术,但是使用c和ruby作了一层简单的封装。Docker的大热让CloudFoundry很纠结;第三,CF使用service broker来集成各种资源服务,如mongo、mysql、rabbitmq和redis等。最后,CF使用消息总线NATS/GNATS来完成应用之间的通讯。 其他基于容器的PaaS平台(如Heroku、OpenShift、DotCloud)的平台架构和上面所描述的模式基本一致,我在附件中提供了若干链接,大家如果有兴趣可以仔细研究。 三、PaaS的参考架构模式 根据上面讨论的两种架构模式,我们可以看到PaaS平台的实现基本需要如下的构件: 路由模块:该模块的基本功能是将终端用户请求路由到对应的服务器实例,并提供应用动态注册等功能。目前绝大多数的实现是基于ngnix,同时也需要使用简单的lua脚本完成应用注册和路由查询等基本功能; 服务管理模块:该模块会为开发人员和运维人员提供管理接口,其基本功能包括创建应用实例、配置应用运行参数、启停应用、发布应用程序、扩容或缩容等。服务管理模块也需要提供相应的客户端被用户使用,如命令行或是用户界面等; 应用容器模块:应用容器是PaaS平台的核心,其主要功能是管理应用实例的生命周期,汇报应用的运行状态等。目前来看,应用容器可以基于虚拟机来实现(如AWS),也可以使用Linux容器技术来实现,最早使用的是LXC,CloudFoundry使用的是自己的warden,同样也是基于cgroup,现在最新的是docker; 应用部署模块:应用部署模块需要将应用程序打包成为可直接部署的发布包。该模块是实现PaaS平台开发性的关键。由于现有通用的PaaS平台需要支持多种编程语言和框架,如Java, Python, Ruby和PHP等,当应用发布时,PaaS平台需要根据不同的编程语言将应用打包成为通用的发布包,然后传递给容器模块部署。应用部署模块是实现这一过程的关键,目前来看起源于Heroku的buildpack已经被大家广发接受; 块存储模块:该模块主要用于存储应用的发布包,需要保证程序包的长久存储和。目前AWS的Beanstalk直接使用S3,CF可以使用网络文件系统NFS或是其他任何分布式文件存储系统(如HBase); 数据存储模块:该模块需要保存应用和服务的基本信息,可以基于任何现有的数据库技术实现,如MYSQL或是MONGODB等; 监控模块:该模块的作用是持续监控应用的运行状态,比如健康状态(是否存活)、资源使用率(CPU、内存、硬盘、网络等)和可用性等。这些指标会成为整个PaaS平台运维的关键,也为自动弹性伸缩奠定基础; 用户认证模块:该模块需要保证应用程序的安全性和隔离性,通常而言,公有云的提供商会使用OAuth等技术集成现有的用户认证服务; 消息总线模块:该模块也是最重要的模块,由于PaaS平台所搭建的是一个大规模分布式环境,通常而言,规模在数百台到上千台的机器数量,所有模块之间的通讯会变成一个核心的问题。所以消息总线会变成系统之间通讯的基础,通常需要支持pub/sub模式。 基于该架构,应用实例的弹性伸缩也能够非常容易的实现。首先需要监控服务来不断获取实时的应用状态,当某些指标超出预先定义的阈值时,平台会启动伸缩服务,首先从应用容器模块预留资源,然后调用应用部署模块打包应用并部署,最后将应用节点注册到路由模块完成整个伸缩的过程。 四、PaaS未来发展的趋势 PaaS通过开放性的设计,能够支持多种不同的编程语言、技术框架和服务,从而为应用开发人员提供了广泛的选择,能够大大提供开发人员的效率。同时,PaaS也从运维层面为企业提供了强大的支持,将以前很难实现的技术场景(如应用弹性伸缩等)转化为可能。最后,基于容器技术实现的PaaS平台也带来了经济性的优势。所以,相比于现有纯资源型的IaaS平台,PaaS确实将云计算平台提升到一个新的高度,距离应用开发更近了一步。

优秀的个人博客,低调大师

Paint类解析

在自定义组件中,Paint类是一个很重要的类,主要包含颜色、文本、图形样式、位图模式、滤镜等几个方面。Paint类的相关方法如下: 1、颜色是指绘图时使用的颜色,在 Android 中颜色可以指定透明度,使用 16 进制来表示颜色 时,格式通常为#AARRGGBB,其中,AA 表示透明度、RR 表示红色、GG 表示绿色、BB 表示蓝色, Color 类定义了颜色信息,内置了常用颜色的 int 型常量,比如 Color.RED 是红色,Color.BLUE 是 蓝色……如果您习惯了 16 进制的颜色, Color 类的静态方法 parseColor(String colorString)可以将 16进制颜色转换成 Color 类型。需要注意的是,Android 的颜色都是 int 类型的,Color 类只负责颜色的管理而不是代表某种颜色。 Paint 类中与颜色相关的方法有: public native void setColor(int color);//设置颜色 public native void setAlpha(int a);//设置透明度,a 的范围取 0~255 之间的整数 public void setARGB(int a,int r,int g,int b);//指定透明度、红、绿、蓝定义一种颜色 2、绘制文本时,可以指定文本的大小、对齐方式、文本样式等属性,文本样式主要是为文本指定粗体、下划线、删除线等修饰性属性,主要说明下设置字体大小这个: public native void setTextSize(float textSize);// 设置文本大小,单位是 px,这个和我们平时使用的字体单位 sp 不同,所以最好进行转换,这个要注意。 比较麻烦的是绘制文字时,我们还要考虑字体的基本结构,字体的信息使用 Paint.FontMetrics 类来表示,该类源码如下: public static class FontMetrics { public float ascent; public float bottom; public float descent; public float leading; public float top; } 从文字上理解可能比较晦涩,看下示意图也许很容易找到答案: 简单来说,常用字符的高度是 ascent 和 descent 的和,但是,一些特殊字符比如拼音的音调等则会延伸到 top 的位置。 baseline:基准点(绿色虚线所指); ascent:baseline 之上至字符最高处的距离; descent:baseline 之下至字符最低处的距离; top:字符可达最高处到 baseline 的值,即 ascent 的最大值; bottom:字符可达最低处到 baseline 的值,即 descent 的最大值。 leading:行间距,表示上一行字符的descent到该行字符的ascent之间的距离 根据世界范围内已入案的使用语言中能够标注在字符上方或者下方的除了类似的符号肯定是数不胜数的,一般情况下我们极少使用到类似的符号所以往往会忽略掉这些符号的存在,但是Android依然会在绘制文本的时候在文本外层留出一定的边距,这就是为什么 top和bottom总会比ascent和descent大一点的原因。而在TextView中我们可以通过xml设置其属性 android:includeFontPadding="false"去掉一定的边距值但是不能完全去掉。 要获取 FontMetrics 对象,调用 Paint 类的 getFontMetrics()即可,而在 drawText()方法中,参数 y 就是 baseline 的值,因为 FontMetrics 类并没有声明 baseline 属性,所以,我们需要通过下面的公式计算出来: int baseline=(int) (viewHeight - fontMetrics.descent - fontMetrics.ascent) /2; 其中,viewHeight 是文字所在区域的高度。 下面自定义一个文本绘制的View public class TextView1 extends View { private static final String TEXT = "Android自定义"; private Paint paint; public TextView1(Context context) { super(context); } public TextView1(Context context, AttributeSet attrs) { super(context, attrs); paint = new Paint(Paint.ANTI_ALIAS_FLAG); paint.setColor(Color.RED); FontMetrics fontMetrics = paint.getFontMetrics(); Log.d("xmr", "ascent:" + fontMetrics.ascent); Log.d("xmr", "top:" + fontMetrics.top); Log.d("xmr", "leading:" + fontMetrics.leading); Log.d("xmr", "descent:" + fontMetrics.descent); Log.d("xmr", "bottom:" + fontMetrics.bottom); } public TextView1(Context context, AttributeSet attrs, int defStyleAttr) { super(context, attrs, defStyleAttr); } @Override protected void onDraw(Canvas canvas) { super.onDraw(canvas); // 将文字放在正中间 Rect textRect = this.getTextRect(); int viewWidth = getMeasuredWidth(); int viewHeight = getMeasuredHeight(); Paint.FontMetrics fontMetrics = paint.getFontMetrics(); int x = (viewWidth - textRect.width()) / 2; int y = (int) (viewHeight - fontMetrics.descent - fontMetrics.ascent) / 2; canvas.drawText(TEXT, x, y, paint); } @Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { Rect rect = getTextRect(); int textWidth = rect.width(); int textHeight = rect.height(); int width = measureWidth(widthMeasureSpec, textWidth); int height = measureHeight(heightMeasureSpec, textHeight); setMeasuredDimension(width, height); } /** * 获取文字所占的尺寸 * * @return */ private Rect getTextRect() { // 根据 Paint 设置的绘制参数计算文字所占的宽度 Rect rect = new Rect(); // 文字所占的区域大小保存在 rect 中 paint.getTextBounds(TEXT, 0, TEXT.length(), rect); return rect; } /** * 测量组件宽度 * * @param widthMeasureSpec * @param textWidth * 文字所占宽度 * @return */ private int measureWidth(int widthMeasureSpec, int textWidth) { int mode = MeasureSpec.getMode(widthMeasureSpec); int size = MeasureSpec.getSize(widthMeasureSpec); int width = 0; if (mode == MeasureSpec.EXACTLY) { // 宽度为 match_parent 和具体值时,直接将 size 作为组件的宽度 width = size; } else if (mode == MeasureSpec.AT_MOST) { // 宽度为 wrap_content,宽度需要计算,此处为文字宽度 width = textWidth; } return width; } /** * 测量组件高度 * * @param heightMeasureSpec * @param textHeight * 文字所占高度 * @return */ private int measureHeight(int heightMeasureSpec, int textHeight) { int mode = MeasureSpec.getMode(heightMeasureSpec); int size = MeasureSpec.getSize(heightMeasureSpec); int height = 0; if (mode == MeasureSpec.EXACTLY) { // 宽度为 match_parent 和具体值时,直接将 size 作为组件的高度 height = size; } else if (mode == MeasureSpec.AT_MOST) { // 高度为 wrap_content,高度需要计算,此处为文字高度 height = textHeight; } return height; } } 效果如下: logcat输出如下: 如图我们得到了top,ascent,descent,bottom和leading的值,因为只有一行文本所以leading恒为0。 从代码中可以发现在我们绘制文本之前我们便可以获取文本的FontMetrics属性值,也就是说我们FontMetrics的这些值跟我们要绘制什么文本是无关的,而仅与绘制文本Paint的size和typeface有关,我们来分别更改这两个值看看效果: paint.setTextSize(36); 如图所示所有值都改变了,我们再为Paint设置一个typeface: paint.setTypeface(Typeface.defaultFromStyle(Typeface.ITALIC)); 3、图形样式包含绘制的图形是空心样式还是实心样式,同时还能指定落笔和收笔时的笔触效 果。绘制直线或折线时,图形样式能影响到一些绘制细节。 Paint 类与图形样式相关的方法有: public void setStyle(Paint.Style style);//设置绘制的图形是空心样式还是实心样式,默认为实心样式,style 的可选值有: public static enum Style{ FILL, FILL_AND_STROKE, STROKE } 其中,FILL 表示实心样式,对于闭合图形来说,会用指定的颜色进行填充;STROKE 表 示空心样式,绘制时只有线条而无填充效果;FILL_AND_STROKE 表示同时使用实心样 式和空心样式。 public void setStrokeJoin(Paint.Join join) 当绘图样式为 STROKE 时,该方法用于指定线条连接处的拐角样式,能使绘制的图形 更加平滑。可选值如下: public static enum Join { BEVEL, MITER, ROUND } 我们通过下图来区别上面三个枚举值(比较右上角即可) ,默认值为 MITER: public void setStrokeCap(Paint.Cap cap) 该方法用于设置落笔时的样式,控制我们的画笔在离开画板时留下的最后一点图形,可选值如下: public static enum Cap { BUTT, ROUND, SQUARE } 我们通过下图来区别上面三个枚举值,默认值为 BUTT: public native void setStrokeWidth(float width) 设置线条的宽度,注意是 float 类型,在 Android 中最细的线条不是 1,可以比 1 更小更细。 参考:http://blog.csdn.net/abcdef314159/article/details/51720686

优秀的个人博客,低调大师

【Kafka核心原理解析】之调优策略解析

上一篇文章中,我们为大家讲解了Kafka的分区分配策略,StickyAssignor分配策略、RoundRobinAssignor分配策略、RangeAssignor分配策略,详细内容参加 Kafka分区分配策略详解,本片文章,我们来看看Kafka的调优策略都有哪些。 ⼀般说到调优都离不开监控,kafka本身没有提供很好的图形化监控系统,但是有很多第三⽅的kafka监控⼯具都做的相对不错: Burrow Kafka Monitor Kafka Offset Monitor Kafka Eagle 在平时的开发中,开发者使⽤kafka来发送数据已经⾮常熟悉,但是在使⽤的过程中,很多开发者并没有深⼊的探索kafka使⽤过程中的参数配置,带来的损失就是没有充分的发挥出kfka的优势,⽆法很好的满⾜业务场景。 生产者配置与说明 Properties props = new Properties(); props.put("bootstrap.servers", "localhost:9092"); props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("buffer.memory", 67108864); props.put("batch.size", 131072); props.put("linger.ms", 100); props.put("max.request.size", 10485760); props.put("acks", "1"); props.put("retries", 10); props.put("retry.backoff.ms", 500); KafkaProducer<String, String> producer = new KafkaProducer<String, String> (props); buffer.memory Kafka的客户端发送数据到服务器,⼀般要经过缓冲,当你通过KafkaProducer发送出去的消息是先进⼊到客户端本地的内存缓冲⾥,然后把很多消息收集成⼀个⼀个的Batch,再发送到Broker上去的。所以这个“buffer.memory”的本质就是⽤来约束KafkaProducer能够使⽤的内存缓冲的⼤⼩的,它的默认值是32MB。既然了解了这个含义,试想⼀下,在⽣产项⽬⾥,这个参数应该怎么来设置呢? 可以先想⼀下,如果这个内存缓冲设置的过⼩的话,可能会导致⼀个什么问题?⾸先要明确⼀点,在内存缓冲⾥⼤量的消息会缓冲在⾥⾯,形成⼀个⼀个的Batch,每个Batch⾥包含多条消息。然后KafkaProducer的Sender线程会把多个Batch打包成⼀个Request发送到Kafka服务器上去。 如果要是内存设置的太⼩,可能导致⼀个问题,消息快速的写⼊内存缓冲⾥⾯,但是Sender线程来不及把Request发送到Kafka服务器。这样是不是会造成内存缓冲很快就被写满?⼀旦被写满,就会阻塞⽤户线程,不让继续往Kafka写消息了。所以对于“buffer.memory”这个参数应该结合⾃⼰的实际情况来进⾏压测,需要测算⼀下在⽣产环境,你的⽤户线程会以每秒多少消息的频率来写⼊内存缓冲。假如说每秒300条消息,那么你就需要压测⼀下,假设内存缓冲就32MB,每秒写300条消息到内存缓冲,是否会经常把内存缓冲写满?经过这样的压测,你可以调试出来⼀个合理的内存⼤⼩。 batch.size batch.size是Batch数据量⼤⼩,默认值是16KB,⼀般可以尝试把这个参数调节⼤⼀些,可以利⽤⾃⼰的⽣产环境发消息的负载来测试⼀ 下。⽐如说发送消息的频率就是每秒300条,那么如果“batch.size”调节到了32KB,或者64KB,是否可以提升发送消息的整体吞吐量。理论上来说,提升batch的⼤⼩,可以允许更多的数据缓冲在⾥⾯, 那么⼀次Request发送出去的数据量就更多了,这样吞吐量可能会有所提升。但是也不能⽆限⼤,过于⼤了之后,数据缓冲在Batch⾥发送出去,那么岂发送消息的延迟就会很⾼。 举个例子,⼀条消息进⼊了Batch,但是要等待5秒钟Batch才凑满了64KB,然后才发送出去。那这条消息的延迟就是5秒钟。所以需要在这⾥按照⽣产环境的发消息的速率,调节不同的Batch⼤⼩⾃⼰测⼀下最终出去的吞吐量以及消息的延迟,设置⼀个最合理的参数。 linger.ms 要是⼀个Batch迟迟⽆法凑满,此时就需要引⼊另外⼀个参数了“linger.ms”。它的含义是,Batch被创建之后,最多过多久,不管这个Batch有没有写满,都必须发送出去了。 举个例⼦,一个batch.size是16kb,现在某个低峰时间段,发送消息很慢。这就导致可能Batch被创建之后,陆陆续续有消息进来,但是迟迟⽆法凑够16KB,难道此时就⼀直等着吗?如果你现在设置“linger.ms”是50ms,那么只要这个Batch从创建开始到现在已经过了50ms了,哪怕它还没满16KB,也要发送出去了。所以“linger.ms”决定了你的消息⼀旦写⼊⼀个Batch,最多等待这么多时间,他⼀定会跟着Batch⼀起发送出去。避免⼀个Batch迟迟凑不满,导致消息⼀直积压 在内存⾥发送不出去的情况。 要配合batch.size⼀起来设置。举个例⼦,⾸先假设一个Batch是32KB,我们需要估算下,正常情况下,⼀般多久会凑够⼀个Batch,⽐如可能20ms就会凑够⼀个Batch。那么linger.ms就可以设置为25ms,也就是说,⼤部分的Batch在20ms内都会凑满,但是你的linger.ms可以保 证,哪怕遇到低峰时期,20ms凑不满⼀个Batch,还是会在25ms之后强制Batch发送出去。 如果要是你 把linger.ms设置的太⼩了,⽐如默认就是0ms,或者你设置个5ms,那可能导致你的Batch虽然设置了32KB,但是经常是还没凑够32KB的数据,5ms之后就直接强制Batch发送出去,这样会导致你的Batch形同虚设,⼀直凑不满数据。 max.request.size 最⼤请求大小 :max.request.size,这个参数决定了每次发送给Kafka服务器请求的最⼤数值,同时也会限制你⼀条消息的最⼤也不能超过这个参数设置的值,你可以根据⾃⼰的消息的⼤⼩来灵活的调整。举个例⼦,发送的消息都是⼤的报⽂消息,每条消息都是很多的数据,⼀条消息可能都要20KB。此时你的batch.size是不是就需要调节⼤⼀些? ⽐如设置个512KB?然后你的buffer.memory是不是要给的⼤⼀些?设置128MB?只有这样,才能让你在⼤消息的场景下,还能使⽤Batch打包多条消息的机制。此时 “max.request.size”可以适当调⼤⼀些,⽐如调节到5MB。 retries与retries.backoff.ms “retries”和“retries.backoff.ms”决定了重试机制,也就是如果⼀个请求失败了可以重试⼏次,每次重试 的间隔是多少毫秒。 确认机制:acks 此配置是表明当⼀次produce请求被认为完成时的确认值。特别是,多少个其他brokers必须已经提交了 数据到他们的log并且向它们的leader确认了这些信息。典型的值包括: 0: 表示producer从来不等待来⾃broker的确认信息,这个选择提供了最⼩的时延但同时⻛险最⼤(因 为当server宕机时,数据将会丢失)。 1:表示获得leader replica已经接收了数据的确认信息。这个选择时延较⼩同时确保了server确认接收 成功。 -1:producer会获得所有同步replicas都收到数据的确认。同时时延最⼤,然⽽,这种⽅式并没有完全 消除丢失消息的⻛险,因为同步replicas的数量可能是1。如果你想确保某些replicas接收到数据,那么你 应该在topic-level设置中选项min.insync.replicas设置⼀下。 min.insync.replicas 当⽣产者设置应答为"all"(或“-1”)时,此配置指定了成功写⼊的副本应答的最⼩数。如果没满⾜此最⼩数,则⽣产者将引发异常(NotEnoughReplicas或NotEnoughReplicasAfterAppend) min.insync.replicas和acks强制更⼤的耐⽤性时。典型的情况是创建⼀个副本为3的topic,将min.insync.replicas设置为2,并设置acks为“all”。如果多数副本没有收到写⼊,这将确保⽣产者引发异常。 消费者端配置和说明 fetch.min.bytes: 每次fetch请求时,server应该返回的最⼩字节数。如果没有⾜够的数据返回,请求会等待,直到⾜够的 数据才会返回。 auto.commit.enable 如果为真,consumer所fetch的消息的offset将会⾃动的同步到broker。这项提交的offset将在进程挂掉 时,由新的consumer使⽤。 更多福利 云智慧已开源集轻量级、聚合型、智能运维为一体的综合运维管理平台OMP(Operation Management Platform) ,具备 纳管、部署、监控、巡检、自愈、备份、恢复 等功能,可为用户提供便捷的运维能力和业务管理,在提高运维人员等工作效率的同时,极大提升了业务的连续性和安全性。点击下方地址链接,欢迎大家给OMP点赞送star,了解更多相关内容~ GitHub地址:https://github.com/CloudWise-OpenSource/OMP Gitee地址:https://gitee.com/CloudWise/OMP 微信扫描识别下方二维码,备注【OMP】加入AIOps社区运维管理平台OMP开发者交流群,与OMP项目PMC当面交流,和更多行业大佬一起交流学习~

优秀的个人博客,低调大师

APP移动端测试点

以下所有测试最后必须在真机上完整的执行1、安装、卸载测试 在真机上的以及通过91等第三方的安装与卸载安装在手机上还是sd卡上2、启动app测试3、升级测试 数字签名、升级覆盖安装、下载后手动覆盖安装、跨版本升级、升级后可以正常使用。 覆盖安装要确保数据库有字段更新的话,能正常更新,否则就容易导致app异常。4、功能测试 包括功能点、业务逻辑、关联性(主要测试客户端与PC端的交互,客户端处理完后,PC端与客户端数据一致)、 服务端接口测试(主要通过访问服务端接口来验证服务端业务逻辑功能点是否正确)5、数据对比测试 可在模拟器或真机上进行,同时与数据库中实际的插入记录做对比。还要对比主站的相同流程6、性能7、安全8、android特性测试(横竖屏,home键,音量键,power键等)9、各种网络状态下进行的测试(包括飞行模式) 3G上网:td-cdma、cdma2000、wcdma能否正常使用。 edge、gprs能否正常使用(主要测试是否支持net接入点和wap接入点)10、中断性测试 如突然来电短信弹出低电量等时app能否正常使用11、app切换测试(最小化、多个app切换)12、关机、待机后app能否正常使用13、兼容性测试 android各种版本各种分辨率QVGA、WVGA、HWVGA等与其他第三方app的兼容14、app在清空数据或强制退出后还能正常运行否15、api,包括在app内跳转到另一个界面,在返回来,以及跳转到系统api16、app对资源的占用(cpu、内存、耗电、流量等)17、app本身涉及的权限18、长时间开机且开app,看是否会出现异常情况19、互动分享:如果程序里面包括分享功能,那么检测点击分享的时候是否会正常给出分享提示,点击分享后所填写的分享内容是否正确

优秀的个人博客,低调大师

移动APP反外挂攻防实战

**> 前言 ** 近日,某某龙在2018年的一次会议上发表了一个演讲,4000多人聚集在现场玩“跳一跳”游戏。随着他们指尖的翻飞跳跃,大屏幕上的现场排名也在不断刷新……而在全场的惊叹声中,最高分出现了,967分!而这位最高分得主,就是某某龙本人。在随后的演讲中,某某龙也表示,这款DAU在一点几个亿的小游戏,网上居然出现了非常多的外挂。笔者以“跳一跳”为关键词在全球最大的同性社交平台github上进行搜索,居然有650个搜索结果。这些外挂,大多数都是以图像识别为基础的游戏辅助程序。利用这些外挂,玩家们可以很轻松的跳到几千分,甚至上万分。 同样,在2018年1月23日举办的阿里游戏云“棋牌X安全”技术分享沙龙的活动现场,阿里巴巴集团安全部专家陵轩也对游戏从业者深恶痛绝的外挂问题进行了详细的解读,并针对反外挂提出了阿里的最新解决方

优秀的个人博客,低调大师

打造IOS移动渗透测试平台

是否要越狱,我纠结了很久。Android平台上有很好的图形化黑客工具dsploit和zANTI。东哥从来没有用过Android系统,就不做过多评价。在触屏上敲命令行是一件非常痛苦的事情。 本着生命不息,折腾不止的精神。 用黑哥的话说“整就牛!” ---------------------------------------------------------------------- 首先越狱 安装OpenSSH,修改默认密码(iPhone默认root/alpine) 安装BigBoss Recommendation tools,几乎所有流行的黑客工具都可以在 BigBoss Recommendation tools这个包中找到。 安装: MobileTerminal,它能够让你在设备上直接运行命令行。 ------------------------------------------------------------------------------------------------------ 现在基本环境已经搭建好,今天先安装metasploit,建议用电脑ssh手机安装。 下载ruby环境 wget http://apt.saurik.com/cydia/debs/ruby_1.8.6-p111-5_iphoneos-arm.deb wget http://apt.saurik.com/cydia/debs/rubygems_1.2.0-3_iphoneos-arm.deb 安装ruby dpkg -i ruby_1.8.6-p111-5_iphoneos-arm.deb dpkg -i rubygems_1.2.0-3_iphoneos-arm.deb 安装metasploit git clone git://github.com/rapid7/metasploit-framework 本文转自文东会博客51CTO博客,原文链接http://blog.51cto.com/hackerwang/1607840如需转载请自行联系原作者 谢文东666

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册