认识达内从这里开始

分布式编程开发系统相信大家应该不陌生了吧。而关于分布式的缺陷或者说问题大家是否有去研究呢?今天我们就一起来了解一下，关于分布式系统中存在的几个问题吧。

网络并不是可靠的

你应该明白，分布式系统中不同节点间的通信是基于网络的。网络使得它们连接起来共同协作。

然而，光缆被挖断的事件相信你也看到过不是一两次了。除此之外，网卡异常、交换机故障、遭受恶意攻击等导致的网络拥塞、网络中断、报文丢失的种种迹象皆意味着网络随时可能无法正常运作，是不可靠的。

此时，需要在你的系统设计中，尽可能地考虑到：当前节点所依赖的其他节点由于各种原因无法与之正常通信时，该如何保证其依然能够提供部分或者完整的服务。这个概念在软件域被定义为“鲁棒性”。

不同节点之间的通信是存在延迟的

网络连接的是处于不同物理位置上的节点，学过物理和数学你的应该明白，两点之间是存在“距离”的，而我们的分布式系统需要在这个距离之上进行数据的传递，本质上就是物质的传递。同时应该你也知道，物质的运动速度不会超过光速。所以，不同节点之间的通信是需要经过一段时间的，也就意味着会存在延迟。具体的延迟是由所用的传输介质、节点当前的负载大小所决定的。

带宽是有上限的

这个点，我相信你是知道的，因为当你通过QQ、钉钉之类的工具传输或者下载一个大文件时候，就发现它是存在上限的，这个上限是根据你的网络带宽大小决定的。但是，为什么你还是有可能会掉入这个陷阱里呢?这往往由于你对所传输的数据的大小和频率没有充分的认识，导致了你觉得达到上限是一个很久远的事情，不用考虑它。

分布式并不直接意味着是“敏捷”了

可能你曾经有过这样的想法，当在规模较大的集中式系统中工作的时候，每次和许多人在一个代码库里提交代码，老是遇到冲突、排队等待上游模块先开发等等。这时你会想，如果改造成分布式系统，这些问题都没了，工作效率高多了。

答案是否定的，在前两篇文章中也有提到一些。拆分后需要做的额外工作如果没做好，可能会导致不是更快，而是更慢。典型的现象如：

发布更麻烦了。原先虽然开发麻烦，但是发布简单啊，哪怕用原始的方式：编译一次，登上服务器，复制黏贴，秒秒钟搞定。而现在需要发布10个、20个、几十个，再这样操作很明显要把人逼疯。

排查问题更难了。原本出了问题，不是在程序就是在数据库。现在还得判断在哪个程序，哪个数据库，是不是要抓狂?

关于这点，你需要秉持着工欲善其事必先利其器的思想。将建设协作相关的辅助性工作与分布式系统同时进行。比如：监控告警系统、配置中心、服务发现，以及批量部署、持续集成，甚至DevOps等。

数据由一份冗余成多份后如何保持一致

这点其实是由于前面提到的网络因素产生的连带效应。

当遇到数据库压力增大，响应开始变慢的时候，你可能会很容易想到，让DBA来做个主从啊。但是，由于网络不可靠、存在延迟、带宽有上限这一系列因素。所以，这个看似只是Copy一下工作，需要我们花大量的精力去解决如何保证在使用不同副本上的数据的时候，都是符合应有的预期的。

关于这点，业界已经研究了几十年，同时得出了许多具有指导意义的理论和思想。你需要充分的理解这些，并且能够识别出合适的运用场景，就可以解决这个问题。这个概念在软件域被定义为「数据一致性」。

节选：infoq

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。