Nosql-分布式

2019 年底，TUG 联合 TiDB 开发者社区举办了“ 我的 TiDB 听我的 ”活动，旨在听取来自 TiDB 使用者的真实呼声，并将收集到的宝贵需求融入到 TiDB 的灵魂和设计中，帮助 TiDB 更好地迭代，以更透明的方式进行版本发布。 “ 我的 TiDB 听我的 ”活动开始后受到了 TUG 成员的广泛关注，大家积极留言，累计收到关于 DDL、分区表、性能优化、KV、PD 等方面的近 40 个需求。这些建议非常务实，并且为 TiDB 4.0 的性能和易用性大幅提升做出了巨大贡献。TiDB 4.0 GA 版本将于 6 月初发布，正是这些广泛而务实的社区需求，帮助 TiDB 更快成长、更受欢迎。 TiDB 4.0 GA 发布在即，而 TiDB 5.0 的设计已然开启。相约依旧，我们期待大家来一吐为快。正是因为您的真实反馈和吐槽，督促我们不断向前。“我的 TiDB 听我的”第二季已经拉开序幕。 活动时间2020 年 5 月 23 日 ~ 6 月 7 日 活动内容第一阶段：需求收集 需求收集时间：2020 年 5 月 23 ~ 30 日** 进入 TiDB 用户论坛 asktug.com 上的活动贴，并在活动贴里留下您对 TiDB 5.0 的需求，可以是新功能，也可以是一些小的功能或者易用性改进，比如优化某某 error message 或者 log 内容等，欢迎您畅所欲言。 ...

出品 | 滴滴技术作者 | 余汶龙 前言：Fusion 是滴滴自研的分布式 NoSQL 数据库，完全兼容 Redis 协议，支持超大规模数据持久化和高性能读写。在滴滴内部支撑了数百个业务，具有 PB 级别的数据存储量，是使用最广泛的主存储服务之一。在支持滴滴业务高速发展过程中，积累了很多分布式存储领域的经验，孵化了离线到在线的高速数据导入方案、NewSQL 方案、跨机房同步等，一路解决了 Redis 容量限制、 离线数据在线打通、数据库扩展性差、异地多活容灾等问题。 本文来自滴滴的技术专家、Fusion 的负责人余汶龙在 2018 年北京 ArchSummit 全球架构师峰会上的演讲内容，重点介绍了 Fusion 的核心设计以及架构演进过程。 内容框架 诞生背景：滴滴业务发展简介演进过程：如何满足业务需求海量存储 FastLoad NewSQL 跨机房多活 总结 & 展望诞生背景 业务 & 架构演进过程 滴滴出行成立于 2012 年，刚开始创业阶段技术主要靠外包解决，没太多技术沉淀；发展到了 2014 年，乘客司机和单量都有不错的增长，我们开始构建自己的系统架构，这个时候业务对于存储的需求很单纯，简单用用 MySQL 基本能解决我们的问题。 到了 2015 年前后，我们的业务线多了起来，专车快车等开始上线，这个时候我们一方面做了中台系统的重构，另一方面感受到了不小的存储压力，即业务数据量和请求量剧增；到了 2016 年，合并优步前后，日订单量逼近 2000 万，进一步挑战我们的存储系统，于是我们按照不同的业务，对存储进行拆分，因为不同的业务对于存储的需求是不一样的，不同的业务对于吞吐、延迟、容量、数据请求大小等都有不同的需求，分库分表也只是缓兵之计。 如何有效应对这些个性化需求呢？于是在这个时候，我们就开始孵化滴滴自己的 NoSQL 数据库 Fusion 了，用它来丰富我们滴滴的存储生态，为业务提供更多的存储选择。 Fusion 是什么？ 前面我们不断提到 Fusion 的关键字，那么是时候正式介绍下 Fusion。Fusion 是一个兼容 Redis 协议的分布式 NoSQL 数据库。定位介于 Redis 与 MySQL 之间的主存储数据库。怎么理解这个定位呢？也就是性能方面我们向 Redis 看齐，即低延迟；持久化能力方面我们向 MySQL 看齐，即 MySQL 具备的多副本、高可用、ACID 事务，我们都是支持的，同时定位为服务打车订单这样的主流程在线业务。 ...