美工需要会哪些软件seo培训优化课程

当前位置： 首页 > news >正文

美工需要会哪些软件,seo培训优化课程,南京 推广 网站建设,dw软件下载近期#xff0c;我们线上遇到了一个性能问题#xff0c;几乎快引起线上故障#xff0c;后来仅仅是修改了一行代码#xff0c;性能就提升了几十倍。一行代码几十倍#xff0c;数据听起来很夸张#xff0c;不过这是真实的数据#xff0c;线上错误的配置的确有可能导致性能…  近期我们线上遇到了一个性能问题几乎快引起线上故障后来仅仅是修改了一行代码性能就提升了几十倍。一行代码几十倍数据听起来很夸张不过这是真实的数据线上错误的配置的确有可能导致性能有数量级上的差异等我说完我们这个性能问题你就清楚了。 我们线上是对接了腾讯云的IOT平台任何iot设备的上传事件都是通过腾讯云的ckafka传递给我们的随着设备量以及事件数据量的增加我们消费腾讯云ckafka出现了性能瓶颈数据高峰期会有数据拥堵从而因数据处理延迟导致业务的问题。解决最简单的方案就是扩partition和consumer实际上半年前我们发生性能问题的时候就是这么做的扩了一倍的partition提升了一倍的性能然而半年后的今天又到了瓶颈。 经过排查发现单条kafka消息处理需要6ms拆分所有执行逻辑后发现这6ms的延迟主要是向腾讯云发送ack的时间我们机房到腾讯云的rtt恰好就是6ms左右所以几乎所有的事件都耗费在消息的网络传输上面了。然而这个是受物理距离所限制无法减减少的。后来偶然发现我们在代码中使用了spring-kafka的AckMode中的MANUAL_IMMEDIATE这个模式下kafka的consumer会向服务端手动确认每一条消息后来我们将这个配置调整成了AckMode.MANUAL单条消息的处理时长从原来的6ms降低到不到0.2ms提升了30多倍这下即便不扩容我们的性能冗余也足够支持很多年了。 为什么简简单单改个配置就会有如此的提升 是否还有其他的配置类型 实际上在spring-kafka中并不是只提供了MANUAL和MANUAL_IMMEDIATE两种ack模式而是有以下七种每种都有各种的作用和适合的场景。 RECORD每处理一条记录后就立即进行确认。BATCH每次调用poll()方法后只确认返回的最后一条记录。TIME每次过了设定的时间间隔后确认最后一条在这段时间内处理的记录。COUNT每处理设定数量的记录后确认最后一条处理的记录。COUNT_TIME组合了TIME和COUNT即满足任意一个条件时确认最后一条处理的记录。MANUAL用户需要手动调用acknowledgement.acknowledge()批量来确认消息。MANUAL_IMMEDIATE用户需要手动调用acknowledgement.acknowledge()来确认消息每条消息都会确认一次。 以上7种模式如果分类的话可以分成2中手动确认和自动确认其中MANUAL和MANUAL_IMMEDIATE是手动确认其余的都是自动确认。手动确认和自动确定的核心区别就在于你是否需要在代码中显示调用Acknowledgment.acknowledge()我们挨个来看下。 手动确认 MANUAL 在此模式下消费者需要在处理完消息后手动调用Acknowledgment.acknowledge()方法来确认消息。确认操作会被批量进行即确认操作被延迟到一批消息都处理完毕后再发送给Kafka。这种模式的优点是可以提高效率因为减少了与Kafka服务器的交互次数。但缺点是如果一批消息消费了一半consumer突然异常宕机因为数据没有及时向kafka服务端确认下次就会重复拉取到消息导致部分数据被重复消费。 MANUAL_IMMEDIATE 在此模式下消费者需要在处理完消息后手动调用Acknowledgment.acknowledge()方法来确认消息。不过与MANUAL模式不同的是一旦调用了acknowledge()方法确认信息会立即发送给Kafka而不是等待一批消息都处理完毕后再发送。这种模式可能会增加与Kafka服务器的交互次数在网络延迟较大的情况下会出现显著的性能消费瓶颈但可以尽快将确认信息发送给Kafka即便是consumer异常宕机也只是会导致单条消息被重复消费。 手动确认的优势在于consumer可以在代码逻辑中自行判断数据是否消费成功未消费成功的数据不确认这样可以保证数据不丢失手动模式可以保证数据的完整性也就是分布式数据系统中所说的at least once。而这两种模式的核心差异就是单条确认和批量确认批量的方式可以显著提升性能 我在上个月的博客IO密集型服务提升性能的三种方法详细介绍过有兴趣可以看下。 自动确认 RECORD、BATCH、TIME、COUNT、TIME_COUNT这5种都是属于自动确认也就是你不需要在代码中显式调用Acknowledgment.acknowledge()只要consumer拉到消息就是自动确认才不管是否真的消费成功所以自动确认的模式可能会导致数据丢失但要注意相对于手动确认自动确认即可能导致数据丢失也可能导致数据重复所以它也不是at most once语义级别的。 虽然同为自动确认但其实这5种模式还有自己的差异。 RECORD和BATCH 首先我们先来看下RECORD、BATCH这两种模式其实就是上文中MANUAL和MANUAL_IMMEDIATE对应的自动版本。RECORD是一条就确认一次同样如果是在网络延迟较大的情况下也会出现性能问题。BATCH是批量确认每次poll()后会确认这一批的消息同样的如果consumer异常宕机也会导致未成功确认消息从而导致消息被重复拉取到。当然如果是consumer因其他原因导致数据处理失败但正常确认了这种情况下会丢失消息。 TIME TIME模式是定时确认比如你设置了确认时间间隔为5Sconsumer就会每5s向kafka确认这5s内消费完的消息这里有个问题是如果是高频数据流且时间间隔设置较大可能导致堆积大量消息未被确认然后异常宕机后重复拉取到这些消息我们接下来要说的COUNT模式可以避免这种情况。 COUNT COUNT模式确认的时机是由消费数据条数触发的比如每消费100条就确认一次完美的避免了堆积大量未确认数据的情况。但是如果是极低频的数据流比如几分钟才一条数据攒够100条得好几个小时数据消费后长时间得不到确认甚至可能导致kafka认为数据消费超时失败从而导致数据被重复消费。 TIME_COUNT 针对于TIME和COUNT的优缺点TIME_COUNT结合了两者的特点只要是时间间隔或者消息条数满足其一就确认具有更强的适应性所以当你想从TIME、COUT、TIME_COUNT三者中选一个的话我个人觉得可以盲选TIME_COUNT除非你特别清楚你数据的特征知道那种更合适。 总结 简单总结下以上几种模式如果是不能容忍数据丢失那一定要选手动模式如果是网络延时比较高可以选MANUAL(批处理)的模式但是注意即便是手动模式它也不能保证数据不重复要想做到完全幂等还得依赖其他的方式比如数据库事务。 如果可以接受部分数据丢失(例监控数据)那就可以考虑自动模式了但我个人还是不推荐RECORD模式因为这种模式会在高网络延迟的情况下啊产生比较严重的性能问题剩下的几种模式可以根据自己的数据量、网络情况选取不同的情况用不同的模式可能会有明显的性能差异。