分布式系统相关问题解决

关于分布式系统很好的文章：http://wetest.qq.com/lab/view/203.html?from=content_toutiao&hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

1、分布式系统中有多个服务器进程，怎么正确处理请求？
一般会设计多个请求转发的服务器(反向代理服务器)来将请求分发至合适的服务器处理。

2、各个进程服务器间如何通信？
可以通过建立TCP连接来通信，但是TCP受网络故障、资源消耗等影响。现在比较新的做法是使用消息队列。

3、请求的高效处理有什么方法？
常用的有：
       多线程
       异步：如NIO
       使用缓存：减轻数据库压力
       使用合适的存储技术：常用的MySQL因为是轻量级数据库，并且数据存储是数据表的形式，像文件数据就无法存储。可以考虑使用Redis这种NoSQL来做数据存储。NoSQL除了更快、承载量更大以外，更重要的特点是，这种数据存储方式，只能按照一条索引来检索和写入。这样的需求约束，带来了分布上的好处，我们可以按这条主索引，来定义数据存放的进程（服务器）。这样一个数据库的数据，就能很方便的存放在不同的服务器上。在分布式系统的必然趋势下，数据存储层终于也找到了分布的方法。

4、分布式系统如何做数据统计，如日志统计？
分布式系统规模太大时，类似于日志的数据统计量是很大的经典的分布式统计模型，有Google的MapReduce模型。

5、如何增强分布式系统的可管理性？

目录服务(ZooKeeper)

问题：分布式系统是一个由很多进程组成的整体，这个整体中每个成员部分，都会具备一些状态，比如自己的负责模块，自己的负载情况，对某些数据的掌握等等。而这些和其他进程相关的数据，在故障恢复、扩容缩容的时候变得非常重要。简单的分布式系统，可以通过静态的配置文件，来记录这些数据：进程之间的连接对应关系，他们的IP地址和端口，等等。然而一个自动化程度高的分布式系统，必然要求这些状态数据都是动态保存的。这样才能让程序自己去做容灾和负载均衡的工作。我们可以自己写一个目录服务器来管理进程状态，但是需要写多个目录服务(不然只有一个挂了怎么办)，太麻烦

Zookeeper解决方案：可以简单启动奇数个进程，来形成一个小的目录服务集群。ZooKeeper的数据存储结构，是一个类似文件目录的树状系统，所以我们常常会利用它的功能，把每个进程都绑定到其中一个“分枝”上，然后通过检查这些“分支”，来进行服务器请求的转发，就能简单的解决请求路由（由谁去做）的问题。另外还可以在这些“分支”上标记进程的负载的状态，这样负载均衡也很容易做了。

消息队列服务（ActiveMQ、ZeroMQ、Jgroups）

问题：两个进程间如果要跨机器通讯，我们几乎都会用TCP/UDP这些协议。但是直接使用网络API去编写跨进程通讯，是一件非常麻烦的事情。除了要编写大量的底层socket代码外，我们还要处理诸如：如何找到要交互数据的进程，如何保障数据包的完整性不至于丢失，如果通讯的对方进程挂掉了，或者进程需要重启应该怎样等等这一系列问题。这些问题包含了容灾扩容、负载均衡等一系列的需求

消息队列解决方案：一般的消息队列服务，都是提供简单的“投递”和“收取”两个接口，但是消息队列本身的管理方式却比较复杂，一般来说有两种。一部分的消息队列服务，提倡点对点的队列管理方式：每对通信节点之间，都有一个单独的消息队列。这种做法的好处是不同来源的消息，可以互不影响，不会因为某个队列的消息过多，挤占了其他队列的消息缓存空间。而且处理消息的程序也可以自己来定义处理的优先级——先收取、多处理某个队列，而少处理另外一些队列。另外一种消息队列，则类似一个公共的邮箱。一个消息队列服务就是一个进程，任何使用者都可以投递或收取这个进程中的消息。这样对于消息队列的使用更简便，运维管理也比较方便。

事务系统与分布式锁

事务系统：在分布式的系统中，事务是最难解决的技术问题之一。由于一个处理可能分布在不同的处理进程上，任何一个进程都可能出现故障，而这个故障问题则需要导致一次回滚。这种回滚大部分又涉及多个其他的进程。这是一个扩散性的多进程通讯问题。要在分布式系统上解决事务问题，必须具备两个核心工具：一个是稳定的状态存储系统；另外一个是方便可靠的广播系统。
        事务中任何一步的状态，都必须在整个集群中可见，并且还要有容灾的能力。这个需求，一般还是由集群的“目录服务”来承担。如果我们的目录服务足够健壮，那么我们可以把每步事务的处理状态，都同步写到目录服务上去。ZooKeeper再次在这个地方能发挥重要的作用。
        如果事务发生了中断，需要回滚，那么这个过程会涉及到多个已经执行过的步骤。也许这个回滚只需要在入口处回滚即可（假如那里有保存回滚所需的数据），也可能需要在各个处理节点上回滚。如果是后者，那么就需要集群中出现异常的节点，向其他所有相关的节点广播一个“回滚！事务ID是XXXX”这样的消息。这个广播的底层一般会由消息队列服务来承载，而类似Jgroups这样的软件，直接提供了广播服务。

分布式锁：所谓的“分布式锁”，也就是一种能让各个节点先检查后执行的限制条件。如果我们有高效而单子操作的目录服务，那么这个锁状态实际上就是一种“单步事务”的状态记录，而回滚操作则默认是“暂停操作，稍后再试”。这种“锁”的方式，比事务的处理更简单，因此可靠性更高，所以现在越来越多的开发人员，愿意使用这种“锁”服务，而不是去实现一个“事务系统”。

日志服务(log4j)

打印日志几乎是服务器端系统在运行时可以用来了解程序情况的唯一有效手段。不过对比日志的打印功能，日志的搜集和统计功能却往往比较容易被忽视。作为分布式系统的程序员，肯定是希望能从一个集中节点，能搜集统计到整个集群日志情况。而有一些日志的统计结果，甚至希望能在很短时间内反复获取，用来监控整个集群的健康情况。要做到这一点，就必须有一个分布式的文件系统，用来存放源源不断到达的日志（这些日志往往通过UDP协议发送过来）。而在这个文件系统上，则需要有一个类似Map Reduce架构的统计系统，这样才能对海量的日志信息，进行快速的统计以及报警。有一些开发者会直接使用Hadoop系统，有一些则用Kafka来作为日志存储系统，上面再搭建自己的统计程序。

自动部署工具（Docker）

6、如何提高分布式系统开发效率？

微服务框架

问题：当我们在讨论服务器端软件分布的时候，服务进程之间的通信就难免了。然而服务进程间的通讯，并不是简单的收发消息就能完成的。这里还涉及了消息的路由、编码解码、服务状态的读写等等。如果整个流程都由自己开发，那就太累人了。

微服务框架：将各个功能模块最为单独的服务，服务之间通过远程调用进行通信，各个微服务独立打包、部署、升级。一般我们的微服务框架，都会在路由阶段，对整个集群所有节点的状态进行观察，如哪些地址上运行了哪些服务的进程，这些服务进程的负载状况如何，是否可用，然后对于有状态的服务，还会使用类似一致性哈希的算法，去尽量试图提高缓存的命中率。当集群中的节点状态发生变化的时候，微服务框架下的所有节点，都能尽快的获得这个变化的情况，从新根据当前状态，重新规划以后的服务路由方向，从而实现自动化的路由选择，避开那些负载过高或者失效的节点。