观点评论|伴鱼数据库选型的思考，为什么我们 all in TiDB( 二 ) all|选型|业务|事

初步验证通过调研我们发现， TiDB 是通过 raft 协议来保证多副本数据的一致性（ ACID 中的 C ），通过 2PC 协议来保证事务的原子性（ ACID 的 A ），通过乐观锁加 MVCC 来实现可重复读的事务隔离级别（ ACID 中 I ），这意味着 TiDB 每一次事务的成本是比 MySQL 要高很多的，特别是有事务冲突的时候（乐观锁的原因），所以性能是需要验证的关键点。
当时伴鱼所有的业务都部署在阿里云上（现在有自建机房），就直接在阿里云上面按 TiDB 的配置要求购买了机器，当时安装的是 TiDB 1.x 的版本。因为 TiDB 官网已经有 Sysbench 的压力测试数据，这个性能数据是符合我们需求的，所以决定对我们的业务场景进行一次完全模拟的长期测试：伴鱼 IM 的并发比较高，并且采用写扩散的设计，对数据库的要求会比较高，所以适合进行验证。通过对 IM 业务的 inbox 表进行双写，业务同步写 MongoDB 和异步写 TiDB ，业务读只读 MongoDB ，这样如果 TiDB 有问题也不会影响线上业务。
在低峰期对 IM 业务开启双写后， TiDB 监控的 999 线和 99 线还满足要求，但是所有 TiKV 节点的 io 使用率一直在 90% 附近波动，这个如果到高峰期是绝对会有问题的，通过重读 TiKV 的配置，在修改配置项 sync-log = false 后， TiKV 的 io 使用率维持在 5% 以下，当天的高峰期也一切正常，没有出现问题。
在这之后，我们对 IM 的双写观察 2-3 个月的时间，在确认一切正常后，再将同步读写都修改为 TiDB 并且异步写 MongoDB ，一切正常并且持续观察。

sync－log 配置是控制 TiKV 数据多副本进行 raft 协议同步的时候，如果 sync－log＝false ，则内存中处理完成就返回 ack ，对于 3 副本来说，单节点故障是不会丢失数据的，同一个 raft 集的 2 个副本同时故障可能会出现丢数据的情况，这个问题除了金融等对数据安全性要求非常高的场景外，其他的业务场景是可以接受的，并且 MySQL 等其他数据库的集群方案在 master 节点故障的时候问题更大。

深度交流在前面初步验证 TiDB 的过程中，一个看似很严重的问题但是调整一个配置就可以解决，这让我们发现了我们对 TiDB 的理解和控制力还不够，在对每一个配置都进行理解研究外，还有一些我们非常关心的问题但没有官方答案。如果对这些问题没有官方答案，那么我们直接使用 TiDB 就是有很大风险的，所以我们决定和 TiDB 团队进行一次深度的交流。
我们当时非常关心的问题列表为：

T- iKV 的线性扩展能力怎么样？
两地三中心架构， TiDB 可以容忍数据中心之间的延迟是多少？
目前业界 TiDB 最大的一个集群的 TiKV 和 TiDB 的节点数、数据量、QPS 最高是多少？
TiDB 哪一些配置是需要特别关注和调整的？
…

收集了大概 20 多个问题，得益于伴鱼和 TiDB 都在北京，离得还非常近，在线上联系上并且约好时间后，和 TiDB 进行了第一次深度的交流。
【观点评论|伴鱼数据库选型的思考，为什么我们 all in TiDB】大概是 2018 年上半年的一天，我和 TiDB 的 3-4 个同事聊了一整个上午，基本都是我将收集到的问题一个个抛出来，大家一起讨论。整个交流过程解答了很多我们关心的问题，也了解到当前业界对 TiDB 的使用情况，大大增强了我们对 TiDB 的信心，对于数据库的选型来说，这是非常关键的事情。
为什么不选择 MySQL？经过对 TiDB 的调研、试用和深入交流后，在传统的关系型数据库 MySQL 和 NewSQL 数据库 TiDB 之间，我们需要做出自己的选择了，这不仅仅是两个数据库之间的选择，这其实也体现了伴鱼对新技术的态度、技术后发优势的理解、成本与效率的衡权和技术生态与红利的思考。
对新技术的态度
伴鱼对新技术的态度是非常积极的，如果业务场景需要的新技术我们都会去了解它、研究它和掌握它，我们相信我们对新技术趋势的判断能力和掌控能力，所以在 TiDB 和 MySQL 的选型的过程中， MySQL 确实是非常稳的选择，并且对我们的需求目前都有现成的解决方案，比如高可用，比如水平扩展能力，只不过不是非常优雅的解决方案，但是 TiDB 无论是理论层面和架构层面都比 MySQL 高出一个时代（MySQL 是面向单机数据库设计的，是这个领域非常优秀的数据库，只是现在伴鱼想要解决的是单机无法存储的海量数据场景，在这个维度上比较确实 TiDB 更好一些，但是这并不是 MySQL 的问题，是因为它们的设计目标不同而已），但是稳定性和成熟度会比 MySQL 要差一些，这个时候，我们选择相信我们对 NewSQL 技术方向的判断力和掌控力，相信 TiDB 的进化能力，相信时间站在我们这边，让子弹再飞一会。
技术后发优势的理解
伴鱼在之前用的数据库是 MongoDB ， MySQL 和 TiDB 都没有用过，如果我们判断 TiDB 更面向未来的数据库，那么我们是先从 MySQL 开始，走一遍 MySQL 的道路，在后面可预见的未来再迁移到 TiDB 上来；还是直接深入研究和掌握 TiDB ，直接 All in TiDB？