本文从个人项目经历来说一点自己对ddbs的理解，包括催生ddbs的原因，ddbs的基本原理，其解决了哪些问题，还有哪些不足。欢迎大家讨论、斧正。

    业务规模较小时，使用单机mysql作存储。但伴随业务发展，存储容量和并发能力会有瓶颈。

    首先，假设单机的硬盘为1.8T，也可以挂更大容量硬盘，但仍有限。

    其次，单机的读写并发能力有限，假设峰值写入qps1000，峰值读取qps3000，网卡对读取时流量也有要求，单次访问的读取量不应过大。

    单机的链接数也有限。

    那么，当使用单机mysql的业务发展，受到以上瓶颈时，一般的思路会是什么呢？一台机器不行，用两台呢，再不行，扩展更多台。

    一台扩展为两台，磁盘容量扩大了，通过分表，将表打散在不同机器上，共同承担写入任务，并发也提高了，感觉这个思路是对的。

    那么在这个过程中，我们需要做什么？

    业务发展到单机无法承受，即使在单机上，很多表应该也做过分表了。一般会根据业务选择分表键。单个表的大小mysql也有一定要求，一般存储量不大于1G，单条记录小一些，一般不超过1k，条数一般不超过1000万条，最多不超过5000万条，否则表的使用和维护效率都很低。假设业务已经做了足够多的分表，满足三年的数据增长需要，第一年过后，每个分表的条数达到200万条，整机存储容量使用了一半，此时我们想拆分为两台机器。

    此时我们可以将原机器上部分表数据同步到新机器上，并在model层抽象一个路由层，将对数据库的操作发到不同的机器上，上层业务仍可以认为在使用单机。此时可以将原机器上不归属自己管理范围的表删除，腾出空间。

    一台变成了两台，向分布式走了一步。此时存储容量和并发都提高了，由路由层管理两台机器。如果两台或今后的多台机器，并发数高于路由层处理能力怎么办？那还要把路由层机器也扩一下，把路由规则都写进去，大家按一个格则办事。

    经过上面的一番折腾，数据库机器水平扩展，解决了单机存在的一些问题。在这个扩展的过程中，是否会对业务产生中断影响呢？

    会有一点影响。至少在路由层改路由表时，会中断数据库的写入，读取此时可以不中断。

    ddbs中，使用到的多台机器，都叫做分片。分片提高了系统存储容量和并发能力，引入分片，也是系统的复杂度提高了，需要引入路由层机器，路由机器也可能需要扩展，复杂操作，还需要添加更多逻辑功能。但至少可以可业务逻辑区分开，业务可以把ddbs当做单机在使用。

    那么ddbs有哪些不足呢？

    ddbs还是要基于分表、分片实现的。那么对数据库的任何操作，首要条件是需要指明操作的分表键。没有这个维度的准确值，就不能对数据库操作，当然除非是备用库，那你随便扫表，因为备用库可以转为冗余安全，不走线上流量，可以做统计任务。

    单指明分表键还不行，还要注意操作的数据可能会分布在不同分表、不同分片中，这样的操作会引发ddbs产生大量并发操作，业务的一个请求就会占用多个机器多个链接，使ddbs得并发能力大打折扣。比如‘where 分表键 in （）’操作，这种操作要慎重，in中个数不可太多。

     分表键最好选用×××，字符串型，可能hash后分配不均，表大小不均衡。

    事物操作在ddbs中的实现，非常耗费系统性能。事务类操作需要路由控制层控制整个操作过程，期中可能涉及多个分片，多个不同的表的操作，对系统整体可用性要求高。