扫盲系列之集群分布式简介

前言

最近部门做的一个项目，为了满足性能和后期的拓展性，我们将项目进行分布式处理。里面运用dubbo进行服务治理，将项目的中的业务由本来的一个系统拆分成相互关联的分布式多系统，后面再将项目中的一个图片和文件单独分离处理，搞一个专门的文件系统。这样就可以看作是一个简单的分布式系统，当然完成的分布式系统还包含很多其他的组件，像是消息中间件等等，后期随着用户量的增大，项目肯定也是要做集群的。由于以前接触的都是些简单的单系统。对于集群和分布式不是很了解，所以这里和大家一起学习总结对于集群和分布式系统的理解。由于自己对于集群和分布式开发经验不多，下面只是简单介绍一些关于集群分布式相关概念，如有错误之处，还请各位大佬指正！

分布式

分布式，这个大家都耳熟能详的名词，听起来逼格很高。我在刚进入公司的时候，那时候由于部门的项目需求都是一些小用户量，也不追求什么效率的。那时候的项目都是单系统项目，什么是单系统项目？就是所有的业务逻辑都是部署在同一台服务器上，数据库也只需要一个就满足需求了，对于数据库也没有什么分库，分表，读写分离啥的，直接一个数据库搞定，有的项目由于项目需求在内外网部署两个数据库就行了。当用户量小的时候，这种简单的单系统项目确实能满足客户需求，也没必要搞那些复杂的东西，毕竟服务器的购买成本和后期维护成本也是不小的。杀鸡焉用牛刀的道理想必大家都懂。
但是随着项目的涉及的行业变多，具体的业务需求和逻辑也比以前复杂了很多，而且用户量也快速的上升，这样的单系统项目就显得很捉襟见肘了。于是项目组长就打算采用那些互联网公司用的比较多的分布式应用，就是将那些项目关联的行业和项目业务逻辑分离在不同的子系统中，然后留出一个专门的门户系统来作为整个分布式系统的门面。这样本来一台服务器的压力就被分摊到多台服务器上面了。

上面所谓的分布式，看起来很完美。组长心想这下应该能够应付用户量的增大了吧。。。好景不长。一天，组长接到一个电话说，部署门户的系统的服务器机房停电导致服务挂掉了，其他的子系统是好的。于是组长打电话给运维，运维跑到机房将门户项目的服务器重启了。重启之后项目可以正常运行了，组长长嘘了一口气。
后来，随着万恶的用户量逐渐变大。。组长发现项目的运行效率又变慢了。原来很多的请求堵在了门户系统之中，导致很多请求在排队，而这样的排队浪费了很多时间。在追求快速响应的客户面前，这种堵塞和排队是不能忍受的。于是，组长没有办法，只能再借鉴互联网项目比较流行的集群。

集群

上面说到，组长打算采用集群的方式来处理上面的用户量增大问题，那具体是怎么集群呢？由于很多请求是在门户系统之中堵塞了，导致后续的请求不能被及时的处理，于是组长决定将门户项目部署在多台服务器上。这样就可以用多台服务器中来分摊一台服务器无法处理的请求。同时这样做还有一个优势就是，当其中某一个服务器挂掉了，部署在其他服务器上的门户项目还是可以照常运行的，这样就可以避免因为某一台服务器停电出现的”单点故障”问题。于是组长打算将同一个门户项目部署到多台服务器上面。集群可以见下图

上面中多台服务器部署好了之后，组长又发现了一个问题，原本是希望请求是被平均发送到每个门户项目的服务上，结果却不是那么如意，组长发现在集群的服务器中，有的服务器上还是有很多请求，由于请求的量很大，导致请求又被堵塞了，但是有的集群服务器却在偷懒。这怎么行，一台服务器价格还是很贵的，怎么能花钱请他过来偷懒呢。。。。组长决定得治治这家伙。

负载均衡

花钱请他过来，他却在偷懒。。。。可是偷懒的服务器一脸委屈的说，不是我偷懒，是没有请求过来啊，我也没办法，只能嗑瓜子，玩玩手机了。于是组长决定再搞一个服务器（例如Ngnix），专门来做负载均衡，就是将来自客户端的请求，转发到集群中的服务器上，这样，每一个集群中的服务器都可以工作了。在这个负载均衡服务器就是将用户请求先拦截，然后再转发到各个集群的服务器中。但是，这样的负载均衡服务器也存在一个问题，那就是“单点故障”问题，没办法，这个负载均衡服务器也需要做集群，这个集群是主从切换，当一个负载均衡服务器挂掉，另外一个就会过来救场。具体的负载均衡策略有很多，什么DNS负载均衡。。。这里就不详细介绍了。下面是负载均衡的图例

Session共享和失效转移

上面的负载均衡解决了请求分发的问题，一切都显得那么美好，但是上面还是存在一个问题的，那就是状态共享问题，在现在的互联网项目中，用户是的状态是很重要的，就比如我们生活中经常用到的的淘宝，京东。双十一快到了，相信小伙伴们估计都要在淘宝或者京东上大战一场了，在双十一前夕，小伙伴们把所有要买的东西都加到自己的购物车中，等待12点的到来。结果因为双十一用户量过大，导致淘宝的集群中的某一个服务器挂掉了，于是用户的请求被发送到的其他的集群服务器中。可是用户被退出登录状态，购物车没了，里面选好的商品也没了，只能再选一遍。而12点马上就要到了，再选一遍肯定来不及抢货了。。这时候小伙伴们心里肯定有千千万万匹草泥马飞过。出现上面这种问题，就是因为用户状态是保存在一个集群服务器之中的，如果这个服务器挂掉了，用户信息就失效了。其他服务器中没有这个用户的状态信息了。对于这种方式该怎么解决呢，有的小伙伴们就想，让每一个服务器都保存用户的信息不就行了吗，一个服务器挂掉，其他服务器上还有用户信息，这种想法是可以实现，但是这些信息的存储会导致服务器的压力剧增。浪费了服务器的资源。现在比较流行的方式就是，用一个专门的服务器来保存用户状态，其他的业务服务器从这个专门的服务器存储中保存和读取状态信息。一般大家都会用redis或者memcache 来实现。下面是session存储的图例

总结

上面就是简单的对集群和分布式的介绍，其实分布式和集群的本质区别还是挺明显的，将一个复杂的，用户量大的系统，根据业务，功能拆分成几个相互关联的子系统，例如文件系统，门面系统，业务系统等等，这里面还有一些数据库缓存系统啥的。。。这些子系统相互协作共同处理成千上万的请求，这就是分布式系统。后来又将门户系统重复部署在多台服务器上，他们的功能是相同的。他们就是所谓的系统集群。通常分布式和集群是相辅相成的，这样才能更好的处理大量的用户请求，对于系统的健壮性，高可用性都是有一定的保障的。同时还有一些全局事务，消息中间件，nginx服务器。。。这些后面再和大家一起学习！