分布式相关应用V-1.0.0

分布式&中间件

分布式是开发人员必经之路，分布式必然用中间件，一下文章是本人对分布式和中间件的一些理解，可能不深，仅限个人理解，可能会用到其他的作品文献等，侵权不删，爱咋咋地。

什么是分布式

分布式系统跟传统单个项目存在着一些差异：

1. 传统项目-存在的问题 ：
   1、模块之间耦合度太高,其中一个功能升级,其他的模块都得一起升级部署。
   2、开发困难,各个团队开发最后都要整合在一起。
   3、系统扩展性差。
   4、不能灵活进行分布式部署

2. 分布式系统-优点 ：
   1、把模块拆分,使用接口通信活着中间件,降低模块之间的耦合度。
   2、把项目拆分成若干个子项目,不同的团队负责不同的子项目。
   3、增加功能时只需要再增加一个子项目,调用其他系统的接口就可以。
   4、可以灵活的进行分布式部署。

总结： 把模块分成独立的工程,单节点运行,如果某一个节点压力大了可以单独对这个节点进行增加配置,其他节点不受影响。缺点就是系统之间交互需要额外的工作量来进行接口的开发。把系统拆分成多个工程,需要完成系统的工程需要多个工程协作完成,这种形式就叫做分布式。；

分布式理论

1. CAP ：CAP理论是分布式系统、特别是分布式存储领域中被讨论的最多的理论。 其中C代表一致性 (Consistency)，A代表可用性(Availability)，P代表分区容错性 (Partition tolerance)。 CAP理论告诉我们C、A、P三者不能同时满足，最多只能满足其中两个。
   CAP理论是分布式系统、特别是分布式存储领域中被讨论的最多的理论。其中C代表一致性 (Consistency)，A代表可用性 (Availability)，P代表分区容错性 (Partition tolerance)。
   一致性 (Consistency):
   一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据。所有节点访问同一份最新的数据。
   可用性 (Availability):
   对数据更新具备高可用性，请求能够及时处理，不会一直等待，即使出现节点失效。
   分区容错性 (Partition tolerance):
   能容忍网络分区，在网络断开的情况下，被分隔的节点仍能正常对外提供服务。

2:BASE
　　 Basically Available 基本可用 分布式系统在出现不可预知故障的时候，允许损失部分可用性
　　Soft state 软状态 软状态也称为弱状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
　　Eventually consistent 最终一致 最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

CAP 与 BASE 关系
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），更具体地说，是对 CAP 中 AP 方案的一个补充。其基本思路就是：通过业务，牺牲强一致性而获得可用性，并允许数据在一段时间内是不一致的，但是最终达到一致性状态。

中间件

消息中间件

消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能；成为异步RPC的主要手段之一。当今市面上有很多主流的消息中间件，比如老牌的ActiveMQ、RabbitMQ，炙手可热的kafka，阿里巴巴自主开发的RocketMQ等。

消息中间件的组成

1、Broker
消息服务器，作为server提供消息核心服务。
2、Producer
生产者，消息的产生者，是消息的入口。业务的发起方，负责生产消息传输给Broker。
3、Consumer
消息消费者，即消息的消费方，是消息的出口，负责从broker获取消息并进行业务逻辑处理。
4、Topic
消息的主题，可以理解为消息的分类，在每个broker上都可以创建多个topic。发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器发布到不同的订阅者，实现消息的广播。
5、Queue
队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定的消息的接收。
6、Message
消息体，每一条发送的消息主体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输。
7、Exchange
交换器：用于制定队列所在交换器，一个交换器可有多个队列；

消息中间件的发布模式

点对点、发布订阅
1、点对点
PTP点对点：使用queue作为通信载体。
点对点发布：消息生产者先生产消息发送到queue中，然后消费者从queue中读取出消息并且消费这个消息。属于一对一模式，不能够进行重复消费。消费完了之后，数据就会被删除了。

2、发布/订阅

Pub/Sub发布订阅（广播）：使用topic作为通信载体。针对topic来说。只要连接上消息中间件、消费者都可以进行消费，只要有权限获取到topic，消费者之间的消费互不影响。

消息生产者（producer）将消息发布到topic中，同时会有很多个消息消费者（订阅）消费该消息。和点对点方式不同的是，发布到topic的消息会被所有的订阅者消费。

queue实现了负载均衡，将producer生产的消息发送到消息队列中，由多个消费者消费。但一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者。

topic实现了发布和订阅，但发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到一个消息的备份。

生产者1，创建的topic为sc。消费完了，数据不会被删除。偏移量会有记录。

消息中间件的作用

1、系统解耦
交互系统之间没有直接的调用关系，只是通过消息传输，所以系统的侵入性不强，耦合度低。

2、提高系统响应时间
比如就像购物一样，完成支付可能会涉及到先修改订单状态、计算会员积分、通知物流配送几个流程才能完成；通过MQ架构设计，就可以将紧急通知（需要立刻响应处理的）的业务放到这个调用方法中，响应要求不高的可以使用消息队列，放到MQ队列中，供消费者处理。

3、为大数据处理架构提供服务
通过消息作为整合，大数据的背景下，消息队列还与实时处理架构整合，为数据处理提供性能支持。

消息中间件的应用场景

1、异步通信
有些业务不想也不需要立即去处理消息。消息队列就提供了异步处理机制，允许用户把一个消息放入队列，但是并不是立即处理它。想要向队列中放入多少消息就放入多少，然后在需要的时候再去处理她们。

2、解耦
降低工程之间的强依赖程序，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是及其困难的。通常消息系统在处理过程中会插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一个接口，当应用发生变化的时候，可以独立的扩展或修改两边的处理过程，只要确保它们遵同样的接口约束。

3、冗余
在有些情况下，处理数据的过程会失败。除非数据被持久化，否则会造成数据的丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。

4、扩展性
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理的过程就可以了。不需要改变代码、不需要调节参数。便于分布式扩展。

5、过载保护
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

6、可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

7、顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。

8、缓冲
在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。

9、数据流处理
分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。

思考：消息中间件挂了，怎样保证消息发送成功。怎样保证一定是消费成功？怎样保证消息不回丢失？如果停电了怎么办mq是怎样处理的？

消息的持久化

	>  https://www.cnblogs.com/ciel717/p/17363789.html

rocketMq的持久化机制：
RocketMQ的消息是存储到磁盘上的，这样既能保证断电后恢复，又可以让存储的消息量超出内存的限制。RocketMQ为了提高性能，会尽可能地保证磁盘的顺序写。消息在通过Producer写入RocketMQ的时候，有两种写磁盘方式同步刷盘和异步刷盘。

同步刷盘：如上图所示，只有在消息真正持久化至磁盘后，RocketMQ的Broker端才会真正地返回给Producer端一个成功的ACK响应。同步刷盘对MQ消息可靠性来说是一种不错的保障，但是性能上会有较大影响，一般适用于金融业务应用领域。RocketMQ同步刷盘的大致做法是，基于生产者消费者模型，主线程创建刷盘请求实例 — GroupCommitRequest并在放入刷盘写队列后唤醒同步刷盘线程 — GroupCommitService，来执行刷盘动作(其中用了CAS变量和CountDownLatch来保证线程间的同步)。这里，RocketMQ源码中用读写双缓存队列(requestsWrite/requestsRead)来实现读写分离，其带来的好处在于内部消费生成的同步刷盘请求可以不用加锁，提高并发度。
异步刷盘：能够充分利用OS的PageCache的优势，只要消息写入PageCache即可将成功的ACK返回给Producer端。消息刷盘采用后台异步线程提交的方式进行，降低了读写延迟，提高了MQ的性能和吞吐量。

未完待续。。。

以上有个人理解，也有其他博主的博客，如有侵权，请联系我。