分布式消息中间件核心要点讲义

1、分布式消息中间要点老胡 知数堂 2018. 01. 25目录壹什么是幕等叁幂等相关基本技术与常识贰处理幂等的重要性肆解决方案第一章内容幂等请输入幻灯片标题文字1笛卡尔乘积重复消费2出现的3造成的问题4笛卡尔乘积x与y坐标分别指什么x是消息多少，y是消费者多少一条数据会被y个消费着消费。消费的操作是新增数据，Y个消费者会新增Y条相同的数据重复消费 是指一条消息被一个消费组多次消费。重复消费出现的范围更加广泛 出现没有解决重复消费问题解决方法没有杜绝三次失败，直接认为请求失败主从关系切换造成 Store文件丢失造成人为操作造成解决维护o fset 在分布式情况下，多个消费无法确定共享多个服务的消费

2、坐标select * from message limit 0 ，200就是无法维护limit后面的第一个值消息中间件不维护消费坐标的正确性，造成消息会被所有消费者获解决识别重复 无法确定获得的消息是否已经消费过 比如消费者A ，执行select * from message消费者B ，执行select * from messagelimitlimit0 ，200100 ，300user消费者A和B在获得数据之后，执行insert into values(.);猜user表里面有多少条数据？ 在执行insert into之前，A与B通过某种。A：我这里有id1到200的数据B：啊，我这里有id

3、为100到300的数据。好吧，我只保存id为201到300 的数据A：我保存id为1到200的数据造成的问题性能损耗的浪费赔钱应用操作异常脏数据的浪费 有12G的数据，十个消费者。会产生120G的网络流量消息中间件需要120G的数据消费者需要接受120G数据消费需要识别重复数据性能损耗 识别重复数据是一种消耗性能的操作 如果不识别，消息被重复执行，也是一种耗性能的举动脏数据 作为开发者原则上是不脏数据出现 mybatis的select0ne方法异常 统计异常 数据量过大赔钱 口述.第三章内容幂等相关基本技术与常识常识唯一，msgId与key，流水号redis安全性，丢失MySQL过期push模

4、式消费模式 CLUSTERING 集群消费 BROADCASTING 广播消费rocketmq的push模式ConsumeFromWhere策略 CONSUME_FROM_LAST_OFFSET一个新的消费集群第一次启动从队列的最后位置开始消费。后续再启动接着上次消费的进度开始消费。可能会丢失数据，重复消费消息少默认方式 CONSUME_FROM_FIRST_OFFSET一个新的消费集群第一次启动从队列的最前位置开始消费。后续再启动接着上次消费的进度开始消费。第一次启动从第一个消息开始消费，出现重复消费历史消息。如果消费大量的历史消息，可能造成新数据，很长时间的延迟。 CONSUME_FROM

5、_TIMESTAMP 一个新的消费集群第一次启动从指定时间点开始消费。后续再启动接着上次消费的进度开始消费。 那种去重方案适合哪个策略？操作模式 id与流水号 需要提前生成不能使用数据库自增,使用分布式序列 使用分布式序列 雪花算法 分布式自增 新增数据 可以使用数据id，msgId，流水号 数据修改 可以使用msgId，流水号第四章内容解决方案重复消费幂等架构设计也造成问题解决方案数据库解决方案redis解决方案没有万能的解决方案，只能适合重复消费也造成问题 识别状态修改与删除数据。除了第一次操作 update user set status = 5 where userId=1 and s

6、tatus = 4 多个状态修改同时触发造成操作失效 优点 简单，超级简单 缺点，之后使用环境限制不支持高性能，性能消耗大批量操作对问题跟踪不利幂等架构设计 不建议这种强行绑定的架构设计 分布式情况下，扩展十分复杂数据库解决方案 第一从数据出来 select * from user where id = ? 或者 in(?,?,?) and status = ？ 第二步与获得的消息进行对比 第三步进行对应的操作 第四步大功告成分析批量错的数据库解决方案的正确 不做批量操作 批量修改操作，使用select * from user where in. update lock 性能非常不好数据库解决

7、方案的正确redis解决方案为什么选择redisredis的解决方案为什么选择redis 每秒轻松四万TPS 社区强大 互联网公司基本都在使用 数据结构丰富 命令执行是数据安全reids常用解决方案.慢慢唯一数据积累越来越多。大家都会选择删除数据，如何删除数据，是一件麻烦的事情。所以选择数据结构是一件很重要的事情。什么时候删除，怎么删除的问题，摆在大家的明前了删除数据可能出现重复消费为什么出现重复消费优化方案如果因为某些执行循序发现改变1.3.4.2.消息push消息去redis验证唯一是否存在把唯一值放到redis中曾经因为网络问题与代码问题造成上面的执行循序，从而丢失几条数据，解决方法：使用主键，把动作1,与动作2的循序换下异常失败，删除主键是否还发现一些问题，如果使用hsetnx与setnx命令是否与上面的方面是一样的？这里优化里面使用的是hdel命令从而减少了redis的内存占用有， 同时解决了上个方面里面，从头开始消费，而造成重复消费的问题重复消费也不会造成问题幂等架构数据库解决方案redis方案一redis方案二难度简单十分复杂相对简单相对简单相对简单环境通用限制十分大