关于分布式的一些思考

关于分布式的一些思考

首先看部署的对象是否“有状态”，所谓的有状态，就是说，当前部署的对象是否会存储数据，如果会存储数据的话就是有状态，否则就是无状态。

1、Java服务实例是无状态的，一般情况下，它是不会存储数据的，当然如果你有本地缓存、本地session等方面的东西，但是这些东西不太符合微服务规范。

2、Mysql、Redis、MQ都是有状态的，因为它们都会存储数据。

对于“无状态”的应用部署，各个部署实例之间不需要状态同步，不需要内部通讯，只是多个实例共同对外提供一样的服务。所以部署就很简单，只要放两个实例上去，就可以保证高可用，只要根据并发量放置对应数量的实例数量，就可以抗高并发，因为不存储数据，所以也不需要考虑海量数据的因素。

对于“有状态”的应用部署，各个部署实例之间就是需要状态同步的，是需要内部通讯的。部署的时候，就需要考虑两个问题，第一个是如何复制，第二个是如何保证CAP。

1、Mysql采用的是半同步复制的方式，来保证数据不丢失，半同步复制在一致性与可用性之间平衡了一下。（主从部署）

2、Redis采用的是异步复制，因为redis作为缓存没必要去保证数据不丢失，而是要保证请求的快速响应，异步复制，保证可用性，不保证一致性。（主从部署，Cluster部署）

3、RabbitMQ采用的是同步复制的方式，保证一致性，牺牲可用性。（镜像部署）

4、ZK采用的是ZAB协议，原子广播的方式（在两阶段提交协议的基础上改进而来），来保证最终一致性，同时会牺牲可用性。

对于网关来说，如果没有存储数据，只是负责请求转发、权限控制、日志打印等等的话，那么网关也就是一个普通的服务，多加几个实例，就可以保证高可用、高并发。网关前面加Nginx实现网关本身的负载均衡。

对于配置中心、注册中心来说，存储的数据为“静态数据”，对于配置中心来说，存储的就是静态数据；对于注册中心来说，除非增加服务实例，或服务实例下线了，才会更新注册中心的数据，而且客户端还会有缓存。所以对配置中心、注册中心而言，更注重的是可用性，可以忽略一致性。