我们生活在一个什么样的世界？
随时都可能出现的流量高峰
很多业务中的突发事件，可能会造成比往常多数倍，甚至数十倍的流量冲击。这些流量会冲击后端架构每一层，但是数据库是最后的生命线，也是最难救的。
为了抵抗随时发生的流量爆发，保证业务不受流量的影响。必须购买支撑“预想中”的业务峰值的物理资源。
Cloud is changing everything
行业普遍现象是平时物理资源利用率只有百分之十左右，而云带来最本质的变化就是从“买房”到“租房”，只需要准备好满足日常需求的物理资源，遇到流量爆发时，可以用“租”的方式满足短时间内的需求来保证正常运转。这也是 Severless 概念的核心——让数据层拥有智能的调度能力。
市面上的 Serverless 主要是面对计算层的，而存储层仍然依靠传统的数据库。其实 Serverless 不应该再去假设底层数据库跑在几台机器，应该根据 Workload、业务弹性调度并精确计算成本。而数据库需要实现 Serverless 的前置条件是调度能力，当业务发生剧烈的流量变化、负载变化的时候，数据库可以根据业务的形态去调整自己的拓扑。需要实现这样的效果，并不是所有数据库都有这样的调度能力，而 TiDB 正是拥有这样的前置条件才能实现数据库层面的 Serverless。
这一点其实早在 TiDB 设计之初，我们就一直在为这个方向在准备，比如想要数据库拥有这样的弹性调度，必须拥有动态分片的能力，而 TiKV 的分片策略便是为此设计的。快速弹性调度同样也有前置条件，而 TiKV 分片大小也是为此而设计。同样在精准性、独立性和通用性上都是针对性设计了各个部分的架构。
在 TiDB 4.0 中这辆概念车即将上路。
当然针对不同的场景，我们可以有不同的「弹性调度」的方式：
-
基于负载的分裂均衡及调整副本
可以在不同的负载，根据实时情况增减副本数量。
-
自动节点扩充
面对流量的大范围起伏，自动增减节点数量，以保证业务顺利、流畅的运行。
-
自动冷热分离、存储介质分离 (WIP)
普通集群有些数据常访问，有些数据长时间无访问。当弹性调度存在时，会自动调整存储介质，降低成本。
-
自主热点隔离 (WIP)
进行弹性调度，把冷热点节点进行切分。
总的来说 TiDB 4.0 可以用两个点来概括：Real-Time HTAP & Serverless，换句话说：TiDB 4.0 是可以自救的数据库。
完整版视频链接：https://www.bilibili.com/video/BV1bA41147oP
精华版视频链接：https://www.bilibili.com/video/BV1Df4y1S7wg
本周四晚 20:00，即将迎来最后一期收官直播：本期主题为 「 ? 」，我们收集了大家非常感兴趣的、有趣的问题：
-
看了之前 TiDB 在 Serverless 上的尝试，感觉不久的未来，DBA 会被时代淘汰，老师们对 DBA 同学有什么建议，以适应时代的需要？
-
电商扣库存并发处理场景（极端情况是秒杀），处理能力大概能达到什么水平？事务控制处理有没有问题，可以是针对中小规模的电商，并发不是十分巨大？
-
TiDB 对 Raft 的实现有哪些比较重要的优化点？
-
关于数据库的 HA 和双活方案，以及可视化的数据流介绍？
-
……
在直播间中，我们会对这些问题一一解答，并且欢迎大家与我们进行互动。
如果你对本次直播感兴趣，点击【这里】，添加 TiDB Robot 为好友并回复【新特性】即可进入直播交流群哦～
欢迎登录 PingCAP 官方网站查看技术文档和博客：https://pingcap.com
若对 TiDB 的使用有所疑问，也可以登录 https://Asktug.com 搜索或发帖交流～
