数据库：高并发下的数据字段变更
1 背景
经常会遇到这种情况，我们的业务已经稳定地运行一段时间了，并且流量渐渐已经上去了。这时候，却因为某些原因（比如功能调整或者业务扩展），你需要对数据表进行调整，加字段 or 修改表结构。
可能很多人说 alter table add column ... / alter table modify ...，轻轻松松就解决了。 这样其实是有风险的，对于复杂度比较高、数据量比较大的表。调整表结构、创建或删除索引、触发器，都可能引起锁表，而锁表的时长依你的数据表实际情况而定。 本人有过惨痛的教训，在一次业务上线过程中没有评估好数据规模，导致长时间业务数据写入不进来。
那么有什么办法对数据库的业务表进行无缝升级，让该表对用户透明无感呢？下面我们一个个来讨论。
2 新增关联表
最简单的一种办法，把新增的字段存储在另外一张辅表上，用外键关联到主表的主键。达到动态扩展的目标。后续功能上线之后，新增的数据会存储到辅表中，主表无需调整，透明、无损。
存在的问题：
读取数据时，联表查询效率低下，数据量越大，数据越复杂，劣势越明显。
并没有彻底的解决问题，之后有新增字段，照样面临是新增表还是修改原表的问题。即使后续新增的字段都加在辅表上，同样面临锁表的问题。
辅表的作用仅仅是解决字段新增的问题，并未解决字段更新的问题（如修改字段名、数据类型等）。
3 新增通用列
假设我们原有表结构如下，为了保障业务的持续发展，后续不间断的会有字段扩展。这时候就需要考虑增加一个可自动扩缩的通用字段。
以 MySQL 为例子，5.7 版本版本之后提供了 Json 字段类型，方便我们存储复杂的 Json 对象数据。
代码中 ext_data 采用 Json 数据类型，是一种可扩展的对象载体，存放被查询数据的信息补充。同样的，MySQL 提供的这种数据类型，也提供了很强大的 Json 函数进行操作。
结果如下：
之前写 MySQL 系列的时候，博客园的一位读者留言要我归纳一下 MySQL Json 的用法，一直没时间，大家可以看一下官网的文档，还是比较清晰的。
Json 结构一般来说是向下兼容的，所以你在设计字段扩展的时候，一般建议往前增，不建议删除旧属性。但是这也有个问题，就是业务越复杂，Json 复杂度也越高，冗余属性也越多。比如上文中我们的 json 包含三个属性，tel、name、address，之后的业务调整中，发现 tel 没用了，加了个 age 属性，那 tel 要不要删除？有一种比较好的办法，是给表加上 version 属性，每个时期的业务对应一个 version，每个 version 对应的 Json 数据结构也不一样。
优点：
可以随时动态扩展属性
新旧两种数据可以同时存在
迁移数据方便，写个程序将旧版本 ext 的改为新版本的 ext，并修改 version
不足：
ext_data 里的字段无法建立索引
ext_data 里的 key 会有大量空间占用，建议 key 简短一些
从 json 中去统计某个字段数据之类的很麻烦，而且效率低。
查询相对效率较低，操作复杂。
更新 Json 中的某个字段效率较低，不适合存储业务逻辑复杂的数据。
统计数据复杂，建议需要做报表的数据不要存 json。
改进：
如果 ext 里的属性有索引之类的需求，可能 NoSql（如 MongoDB）会更适合
文章福利】另外小编还整理了一些 C++后端开发面试题，教学视频，后端学习路线图免费分享，需要的可以自行添加：学习交流群点击加入~ 群文件共享
小编强力推荐 C++后端开发免费学习地址：C/C++Linux服务器开发高级架构师/C++后台开发架构师
4 新表+数据迁移
4.1 利用触发器进行数据迁移
整个步骤如下：
新建一个表 t_user_v1 (id, name, age, address, sex, ext_column)，包含了扩展字段 ext_column
在原有表上添加触发器，原表的 DML 操作（主要 INSERT、UPDATE、DELETE），都会触发操作，把数据转存到新表 t_user_v1 中
对于旧表中原有的数据，逐步的迁移直至完成
删掉触发器，把原表移走（默认是 drop 掉）
把新表 t_user_v1 重命名（rename）成原表 t_user 通过上述步骤，逐渐的将数据迁移到新表，并替换旧表，整个操作无需停服维护，对用业务无损
4.2 利用 Binlog 进行数据迁移
如果是 MySQL 数据库，可以通过复制 binlog 的操作进行数据迁移的，效果一样，比起触发器，更稳定一点。
4.3 存在的问题
操作繁琐，效率低下
数据迁移和数据表切换之间存在操作间隙，对于高并发、高频操作的数据表，还是有风险的，会引起短暂连接失效 和 数据不一致。
对于大数据表，同步时间长
5 字段预留
预留字段 和 字段与表格名称映射的办法。
5.1 存在的问题
同样的，查询效率低
预设存在未知数，可能存在预设的字段不够，也可能存在空间冗余
冗余过多的空子字段，对存储空间的占用和性能的提升存在阻碍。
该方法还是比较笨的，不适合程序员思维
6 多主模式和分级更新
如果业务流量比较小，可以直接在表上进行字段新增或者修改，短暂的写锁是可以承受的。但如果是高并发、集群化、分布式的系统，则从数据层面上就应该进行主从或者分库分表治理。以下是典型的的多主要模式下，进行数据库表结构升级的过程。
正常两主模式下，主主同步，可以使用 DBproxy、Fabric 等数据中间件做负载均衡，也可以自己定义一些负载策略，比如 Range、Hash。
修改配置，让流量都切到其中一台上，然后对另外一台进行数据表升级（比如切 DB1，只使用 DB2）。切记在业务低峰期进行，避免流量过大导致另外一个数据库实例负载过大而挂起。
轮流这个操作，但是这时候不需要再升级 DB2 了，因为是主主同步。DB instance 1 已经是新的表结构了，这时候会连同架构包括数据一起更新到 DB2 上。
等两个数据库实例都一致了，修改配置，重设两个数据库实例的负载，恢复到之前的状态。
参考资料
推荐一个零声教育 C/C++后台开发的免费公开课程，个人觉得老师讲得不错，分享给大家：C/C++后台开发高级架构师，内容包括Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK等技术内容，立即学习
还未添加个人签名 2022.05.06 加入
还未添加个人简介
评论