分布式、中间件和消息队列、集群
分布式、中间件和消息队列、集群
From今日头条：
https://www.wukong.com/answer/6534675344568353032/?iid=28070358035&app=news_article&share_ansid=6534675344568353032&wxshare_count=1&tt_from=weixin&utm_source=weixin&utm_medium=toutiao_android&utm_campaign=client_share
https://www.wukong.com/question/6506283491167043844/?app=news_article&share_ansid=6533256199767326979&iid=28070358035&wxshare_count=1&tt_from=weixin&utm_source=weixin&utm_medium=topic_android&utm_campaign=client_share
一、分布式
相对以前单一系统，所有功能、服务都部署在一台服务器上，一挂全挂！
分布式采用了把系统提供的服务分布在不同的服务器上的策略，这样的架构就叫做分布式架构！
【一个业务被拆成多个子业务，部署在多台服务器上，这个就叫做分布式】
【分布式架构图】
实例：
我有一个系统A，提供一个很简单的接口，根据员工编号查询员工姓名和他的考勤记录。
我拆开两个系统：人员管理系统B和考勤系统C，分别部署在两台服务器上。
这个需求，需要调用一下系统B，再调用一下系统C，最后得到需要的结果。
这个就是分布式。
分布式架构优势：
1，单个服务宕机不影响别的服务正常运行！
2，单个节点所有的负载分布均衡到了多台服务器上！
3，各服务之间相互透明，实现解耦！
注意：
分布之后问题来了，以前的单一系统，所有服务都在同一个机器，在同一个内存里面，直接调用即可；
但现在分布在不同的jvm中，怎么调用呢？或者说数据怎么传输？ --消息中间件应运而生！
二 、中间件
中间件：将具体业务和底层逻辑解耦的软件
目前应用较多消息队列有ActiveMQ，RabbitMQ，Kafka，RocketMQ，ons，它们又可以被称作是消息中间件。
消息中间件解决的就是分布式系统之间消息传递的问题。
1，生产者和消费者之间通过某种方式（点对点或者订阅）实现"绑定"！
2，生产者生产数据，并发送到消息中间件，消息中间件进行落库处理！
3，订阅了消息的消费者通过监听器监听消息中间件，如果有属于自己的消息，进行消费！
注：整个过程中间会有数据一致性问题，怎么解决呢？
【1】保证生产消息到消息中间件的时候进行返回值确认保证这一步的数据一致
【2】在消息到消费者的时候保证返回正确结果即可，如果中间出现异常可进行重试，或者发邮件等
到此，分布式系统的数据传递通过消息中间件解决了！
但分布式还有如session、日志处理、单点登录等各服务器需要相同数据的问题，可通过接到同一个redis缓存进行处理！
分布式服务的配置文件可以通过统一的文件配置中心统一处理！
添加服务注册和发现，还有服务宕机的监控处理！
例子：
我要开一家炸鸡店（业务端），需要鸡肉，有很多养鸡场（底层），我需要一个一个比较价钱，然后找一家性价比高的养鸡场合作（适配不同底层逻辑）。可能一段时间后，我需要重新选一家养鸡场合作，进货方式、交易方式等要重新制定（重新适配）。
这一套事情太复杂了，于是我找到了一个专门整合养鸡场的第三方代理（中间件），跟他谈好价格和质量后（统一接口），以后我就只需要给代理钱，然后拿肉就行。具体这个第三方代理怎么操作，我不用管。
三、消息队列
消息队列可以看做内存中的队列，有人往里放消息，有人从里取消息。
1、Producer：消息生产者
2、Broker：消息处理中心，负责消息存储、确认、重试等
3、Consumer：消息消费者
消息队列的特点是：异步、解耦、可靠性（消息队列一般会把接收到的消息持久化到本地硬盘上）
例子：
我是做网上商城的，有一个短信系统，当客户下了一个订单之后，通知客户你下单成功。
当订单量比较小的时候，只需要调用发送短信的接口就可以了。
但是如果订单量大了之后呢，并且短信发送晚个一两分钟也没有什么问题，那么就可以使用消息中间件：把待发送的短信发送到消息队列里面，短信系统从消息队列中取出短信进行发送就可以了。
而且还有一个好处：如果短信系统挂掉了，短信消息保存在消息中间件里面不会丢失，等短信系统恢复了之后，继续短信发送即可。
四、分布式和集群
集群：同一个业务，部署在多台服务器上，这个就叫做集群。
单机模式的系统：单机模式是说一个服务器就部署一个应用，一个应用上包含很多功能，当用户规模小，请求数不多，那么这个单机模式可以支撑业务，但是如果访问量特别大，你会发现一个服务器无法支撑大的访问量，于是为了解决这个高并发的问题，就产生了集群的概念，就是用好多服务器，每个服务器上部署相同的应用。这个就能支撑高并发请求了。
集群里面，每一台服务器实现的功能没有差别。
比如我有一个系统A，提供一个很简单的接口，根据员工编号查询员工姓名和他的考勤记录。
当有一个系统调用这个接口的时候，我部署一台服务器就够用了。
当有一百个系统调用这个接口的时候，我就部署十台服务器，前面挂一个负载均衡。
这就是集群部署，当一台服务器挂了以后，不影响功能使用。
【集群部署】
分布式：一个业务被拆成多个子业务，部署在多台服务器上
分布说明应用是分散在不同的服务器上的，当集群无法满足业务需求时，业务耦合度高，需要降低各功能模块的耦合度，因此就对一个大系统进行拆分成小系统，单独部署，易于维护，这就产生了分布式。
分布式里面，每一台服务器实现的功能是有差别的，分布式每台服务器功能加起来，才是完整的业务。
还是这个业务场景，我有一个系统A，提供一个很简单的接口，根据员工编号查询员工姓名和他的考勤记录。
我拆开两个系统：人员管理系统B和考勤系统C，分别部署在两台服务器上。这个就是分布式。
好处是什么呢？
如果有系统D也需要使用人员信息，传统的方式系统A和D都要有人员信息管理功能，意味着两个系统各自维护人员信息，那新入职一个员工，可能要在系统A和D里面都维护；如果是有EFGHI系统都需要人员信息呢？
而分布式解决了这个问题，人员信息单独拎出来是一个系统，维护人员信息，同时对外提供查询服务。
分布式主要是应用在大型网站系统，比如天猫，淘宝等，集群一般配合分布式使用。
分布式+集群
很多时候要结合起来一起用。
还是这个业务场景，我有一个系统A，提供一个很简单的接口，根据员工编号查询员工姓名和他的考勤记录。
我拆开两个系统：人员管理系统B和考勤系统C。
那么系统B部署在十台服务器上，系统C部署在十台服务器上；前面分别挂负载均衡；这样保证了每个子业务功能的高可用。
