JAVA分布式理解：第一弹

分布式理解：第一弹

大学刚学JAVAWEB的时候，前后端在一个project里，租一台阿里云的服务器，tomcat+mysql部署一下，齐活了！

后来毕业去给某某音乐做了一年外包，虽然只是写写业务接口，但是耳濡目染还是学到一些“架构”上的东西…的皮毛：

• 分布式缓存：Redis集群
• 分布式数据库：mysql
• 消息队列：RabbitMQ

这几个是当时搬砖的时候能接触到的，Redis做缓存这个很好理解，那分布式缓存呢，不就是在多个机器上部署redis，搭成集群，这样挂掉一个也不会影响系统正常响应，这就是分布式的高可用。这种集群的套路应该是分布式里最常用的，正所谓万物皆可集群。

那么同理，mysql也是一样，在数据量比较大情况下会考虑数据库的分库操作，将不同的业务数据分到不同节点的数据库服务器上，这样既能分担存储压力，也能分担并发访问带来的压力。

当然，一个大型的系统大概率会由多个业务部门开发完成，彼此之间通过接口或者MQ来通信，在有开发能力的情况下，一般不会对外直接提供数据库，就会出现如下情况：

就像当时我是在歌单组，我想要查用户信息就必须调用用户组的接口获取数据，而不能直接访问他们的数据库查数据。这里，站在我的角度来说，mysql并不是分布式的，但是对于整个系统来说mysql却是分布式的：

对于业务系统1来说，它只有一个数据源DB1。其他的DB2和DB3对于业务系统1来说是不可见的，但是对于整个完整的系统来说，数据源分散在DB1-3个节点上，就是数据库的分布式部署。再说业务系统1-3，也是分散在不同节点上面，也是分布式部署，当个节点的服务器挂了，也只是业务1不可用，不会导致整个系统不可用。

那么业务系统1向业务系统2索要数据怎么实现呢？第一感觉就是走接口，那么实际中也是这么干的，但是呢在一些请况下我们还可以优化一下：

假设有类似于上图这样的串行业务，完成这样的一次操作耗时就是（3+2+1=6s），当然这种简单的业务处理也不会耗时这么长，这里只是举例说明。那么，在这次操作中业务A是主要业务，即便没有业务B和业务C（或者B/C执行失败）也应该让用户完成登录操作，作为客户来说，业务BC应该是透明的，可以做以下调整来提升下响应速度：

消息队列（MQ）登场，实现串行到并行，主业务A处理后，将异地登入消息发到MQ中，然后直接响应客户端，订阅了MQ的业务B/C就能收到异地登入消息进行后续处理。什么？怕MQ挂了，那就老办法，集群整上！

量力而为

子曰：越复杂的系统，BUG越多！

如果你就是做个考勤系统，管一下办公室里几十号人的考勤，分布式？？呵呵，洗洗睡吧！当然也不是不行，只是没这个必要嘛，财大气粗的壕团队就另说了，不算编码的成本，就光是几个集群服务器的运维也是不小的一笔经费。

开个头，下集再见。