京东云总监带你吃透分布式精髓(含视频)

以C++为例，一个List操作支持pop/push，也可以支持在List中间去Insert/erase。对于Redis而言，除了常见的操作之外，我看了一下Redis整体的release history，最开始的时候也支持的是一些比较简单的操作，例如pop/push;随着时间的发展，支持越来越多的高级功能，都是建立在普通的操作上。

比方说BRPOPLPUSH这个功能，就是从一个List中POP一个数据出来，插入到另外一个List中去，这算是比较高级的功能体现了，但这个也是在用户发现其需要此种场景之后才去增加的事项。

再来探究下MongoDB。MongoDB的“工作”其实与Redis有点类似，可以认为Redis就是利用K/V结构，将Strings换成了一个类似于JSON的类型，JSON中可以支持的数据结构也非常多。

MongoDB所体现的功能相似度很高。以前在设计数据库的时候，如果是关系型数据库，一开始就需要将Schema设计好，然后去做一个DDL操作。当需要增加一列或者减少一列的时候，以上的操作并不是很方便;特别在表单很庞大的情况下，操作时间会很长。

随着业务的发展，是否可以用一个JSON来代替原型MySQL Schema?以这样一种简单的想法出发，如今尽管MySQL或者关系型数据库还是以Schema为核心，但是MongoDB就以Document，也就是JSON这个格式为核心去构建整个数据库的功能和生态。

可以看到，MySQL的常见SQL语句在MongoDB中命令长度不太一样，因为所有的命令都与JSON的格式有关，包括底层的存储结构也会因为要保存JSON格式而做出很大变化。

这部分集中想要表达的观点就是很多数据库以及技术产品的演进，其实都是有脉络可寻的，主要就是设定解决问题的目标进而完成底层数据结构的修改，其中底层结构确定之后还会在一定程度上影响产品功能，例如MongoDB在很长一段时间内都不支持事务，不是不想去尝试支持，而是取决于底层存储结构的存储引擎，无法支持事务。

同样的道理，探究Memcached和Redis的内存管理设计，也会发现，Memcached的开发者或者说社区，也想去支持像Redis一样的功能，但事实上由于底层的存储结构注定无法提供此类服务。

2分布式从何而来?

为什么会有分布式?主要还是由于处在信息爆炸的时代，业务量逐渐庞大导致单机数据库并不能更好满足需求，自然要寻找一些可行的解决方案。

这里的解决方案可以分为两种，一类相当于表层的解决方案，操作起来比较简单，其中涉及客户端的方案以及统一代理的方案等，例如proxy的方案。

相比之下，底层的方案可以分为三类。第一类是分布式块存储方案，第二类是计算与存储分离方案，第三类就是要另起炉灶了。

首先客户端方案，可以以友商开源的项目称为TDDL为代表，方案思路较为清晰。如果我们自身需要做一个分布式系统的话，将分布式解决方案放入客户端内，最重要的就是“告诉”客户端SQL语句应该链接到背后哪个数据库，毕竟不同的数据存储在不同的机器当中。对于客户端的方案，比较重要的就是与后端的一些连接，以及如何解析这个SQL语句。

第二种方案就是Proxy方案。Proxy方案相对客户端方案而言，开发难度稍微高一些，但思路上还是非常一致的。举例说明，一张用户表，用户表的组件是ID，我们对ID的分布式key进行分布，查询具体某一个用户ID的时候其实就有一个Proxy，如果说查询这个用户ID为0，进而就知道0是存在于后台的哪一台MySQL。

所以对于Proxy而言，非常重要的一点还是需要去解析具体的SQL语句，这个过程中必须需要有一个自己的路由，就可以完成识别。

客户端的方案与Proxy方案的区别在哪里?区别在于客户端的方案开发起来相对比较简单一点，在JDBC中或者要求客户端调用时，客户端可以不解析SQL语句，完成导向很容易。

对于Proxy方案，它需要兼容原有的MySQL协议，怎么建立MySQL连接，怎么与后端保持连接，这个难度比较大。但相对而言，Proxy方案的限制也比较多，不管是客户端的表层方案，还是Proxy的表层方案，它们对SQL的使用要求都是比较高的，例如一些join是比较难支持的，而且要与业务方达成一致。

此外，无论是客户端方案还是Proxy方案，整体架构还是比较类似的。例如Proxy方案，它会涉及前端如何与客户端进行连接以及后端的Backend connection，还要与后端真正提供MySQL服务的保持连接，这是两个连接的管理。

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!