gaokuo的博客

进行到通知的partition-leader时候partition-leader所在的broker挂掉了，同时选取了已经持久化成功的从partition作为新的leader，就会出现重复消息，因为这时生产者会重新上报这条消息。对于上述步骤，partition-leader回复生产者成功的触发条件是可以配置的，有三种策略：只要leader持久化成功就返回、至少一个从partition成功就返回、全部partition成功才返回。解决方式：kafka提供了配置，同一个生产者提交的重复key对应的消息会被忽略。

比如说现在需要统计一张传统数据库表中的某个字段词频，按照每天一次统计，由于我们的应用内存受限，无法容纳一天全部的数据，所以我们采用分时段统计的方式，这是理所当然的，这时候数据倾斜问题就可能找到我们。造成问题的原因往往是对于数据的分布不够了解，比如这张表的数据是由其它系统上传，那么其它系统大概率会选择凌晨上传，这会导致某几个小时内数据的占比格外的大，我们统计到这部分就可能出现内存溢出等风险。只要对数据的访问、处理使用分治的思想，就会面临潜在的数据倾斜问题，严重的数据倾斜会导致任务执行缓慢甚至失败。

大部分的情况下，应该是这样的，大量的读请求过来，都是直接走缓存取到数据的，少量情况下，可能遇到读跟数据更新冲突的情况，如上所述，那么此时更新操作如果先入队列，之后可能会瞬间来了对这个数据大量的读请求，但是因为做了去重的优化，所以也就一个更新缓存的操作跟在它后面。2）是做实时性要求不高的数据，比如说商品的基本信息，等等，我们采取的是三级缓存架构的技术方案，就是说由一个专门的数据生产的服务，去获取整个商品详情页需要的各种数据，经过处理后，将数据放入各级缓存中。读的时候，先读缓存，缓存没有的话，那么就读数据库。

cglib