ONS

前言.... octotree 是一款chrome插件，用于将 Github 项目代码以树形格式展示，而且在展示的列表中，我们可以下载指定的文件，而不需要下载整个项目 源码地址： https://github.com/buunguyen/octotree 下载地址： Chrome 浏览器： Chrome Web Store Mozilla 浏览器： Mozilla Add-ons Store Opera 浏览器：： Opera Add-ons Store 更多安装方法可以查看 ： https://github.com/ovity/octotree/blob/master/README.md 来源： https://www.cnblogs.com/JonaLin/p/11691438.html

消息中间件的产生主要是为了达到以下目的： 异步 解耦 最终一致性 并行 下面我们来看针对同一件事情，不同的处理办法： 过年了拜年发微信： 普通青年：编辑微信，群发给所有人。 文艺青年：编辑微信，交给美腻秘书发送，自己已去...... 二笔青年：编辑微信，发送；编辑微信，发送；编辑微信，发送；.......... 我们现在主要关注第二种场景，它的使用方式实现了解耦操作和异步操作。 举一个淘宝的简单例子： 一笔交易的完成涉及到很多系统协调操作的过程，如上多个系统，但如果只是串行的执行这些操作，可能还没执行完这些操作，用户可能已没有耐心，离开了操作界面。给用户留下不好的用户体验。 现在消息中间件就派上了用场： （以下截图都取自阿里沈询消息中间件ONS讲解） 消息中间件具有减少延迟，提升用户体验（异步解耦） 最终一致性：如果由于消息中间件消费端的一个模块 crash 了，而出现的短暂不一致现象，而该模块恢复以后会重新完成它的操作，最终保证数据操作的一致性，我们可以使用消息中间件来保证最终状态的统一。 并行：因为消息时并行发送到各个消息队列的，也是并行的被各个系统进行处理的，系统的高效可以由此得到保证。 ONS的设计思路： 消息中间件的难点主要是在于权衡和取舍。 设计假定： 每台PC机器都可能down机不可服务 任意集群都可能处理能力不足 最坏的情况一定会发生

产生的原因：网络不可达问题。 网络超时之后我们可以做的只有两件事，1 停止（回滚，但对于系统来说影响特别大） 2 继续（另发送到别的服务消费端） 一般我们采用第二种处理方式，但是要经过网络，必然会出现消息重复问题。 最好的解决方法是： 恰好不需要——幂等操作 S * S = S (某个操作不管重复多少次，结果都一样)。 幂等消息去重： 保证有个唯一ID标记每一条消息 保证消息处理成功与去重表日志同事出现 代价：去重代价是去重日志的写入，数据校验，多台机器对去重表的维护。 ONS消息与事物转账设计难点： 如何保证消息发送与Bob账户减钱同时成功或同时失败？ 消息处理超时的解决？ 消息处理失败如何解决？ 尽量保持消息接受者的幂等性 但是对于非幂等的消息消费端：要记录日志表，内次执行时进行日志校验。 当消息接收者处理失败时，能挽回失败的方法之一是系统，但是系统回滚的开销往往是很大的。 还有一种方式是人工处理，当事件发生的概率 比 写代码挽回失败Bug的概率还要小，这样我们就需要考虑是否使用人工处理了。 利用努力送达模型，失败后再重新发往mq中，重新进行消费，尽量保证数据处理成功。努力送达模型是系统希望来进行这样的设计的。 小结： 消息系统：解耦 异步 最终一致性 并行 ONS 和其他消息系统不一样的部分：高吞吐量 高并发。 面向于失败的系统： 消息安全性， 消息堆积能力 消息吞吐量 和

顺序消息：消息的有序是 消息消费时，能够按照发送的顺序进行消费。 例如：假如生产者产生的两条消息M1 、M2 要保证两条消息的顺序来消费应该怎么做，我们可能想到这样的场景： M1发送到S1 ， M2发送到S2，如果保证M1先于M2被消费，需要M1到达消费端后，通知S2 ， 然后S2再将消息M2发送到消费端。 这个模式存在的问题是：如果M1，M2分别发送到两台Server，由于两台Server服务器的网络环境可能不同，所以，不能保证M1先到达， 所以也就不能保证M1先被订阅者消费。那么就要在MQServer集群维护消息的顺序，如何解决：其中一种解决方式是把消息发送到同一台消息服务器上。 这样可以保证M1先于M2到达MQServer(客户端等到M1发送成功后再发送M2)，根据先到达先消费的原则，M1会先于M2被消费，能保证顺序。 这个模型，理论上可以保证消息的顺序，但实际运行中你可能会遇到下面问题。 只要将消息从一台服务器发往另一台服务器，就会出现网络延迟问题，如上图所示，如果发送M1耗时大于发送M2耗时，那么M2就先被消费，仍然不能保证消息的顺序，即使M1和M2同事到达消费端，由于不清楚消费端1和消费端2的负载情况，仍然有可能出现M2先于M1被消费。如何解决这个问题？ 将M1和M2发往同一个消费者即可。且发送M1后，需要消费端响应成功后才能发送M2。 但是会引入另外一个问题