在 《企业应用架构模式》 中 提到了 乐观锁定,
用 时间戳 来 判定 交易 是否有效, 避免 传统事务 的 表锁定 造成 的 瓶颈 。
在 现在的 大并发 的 大环境下, 传统事务 及其 表锁定 以及 事务带来 的 性能消耗, 确实 不能适应 当今 的 大并发 的 场景 了 。
感觉 传统事务 也就只能用在 办公系统 了, 哈哈哈哈 。
但是 传统事务 的 表锁定 是 合理的, 表锁定 使得 事务中 其它 线程 不能 读写 表 。
不能 写, 这个容易理解, 不能 读 是怎么回事 ?
因为 读取表的结果 会 作为 系统 决策行为 的 依据, 所以 也不能 读 。
比如, 一个商品已经卖出去了, 就不能再卖给其它用户 。
那么, 用 乐观锁定 能解决这些问题吗 ?
乐观锁定 的 提出 是 很有意义的,
但是不太靠得住, 为什么呢 ?
时间戳 通常 取到 毫秒, 但 如果 并发密度 超过了 毫秒级, 达到了 比如 微秒级, 那 ?
当然 理论上 可以随机的取 其中 一个用户 作为 成功者, 其他用户作为 失败者(牺牲者?) 。
不过 理论上, 这还不是一种 完备 的 做法 。
我们再来看看 Redis 锁定,
Redis 提供了 对 数据(对象) 的 锁(Lock), 以及 队列 Queue 等 数据类型, 以及 对 Queue 的 Block 操作 。
我们可以利用 Redis 来锁定 某个 ID 的 业务实体 (某个 订单号 的 订单), 然后 对 这个 业务实体(订单) 进行 相关的操作(事务 / 交易),
这样 达到 多个 线程(用户) 对 同一个 订单 的 操作(交易) 顺序进行 。
这种做法 的 实质 是 行锁定 , 那为什么不通过 数据库 来实现 行锁定 呢 ?
因为 我 不知道 数据库 行锁定 的 语法,,,,,,
其次, 数据库 行锁定 的 实现 会 更加 复杂 和 重量,
Redis 的 对象锁 则 简单 而 轻量 。
事实上, 如果 把 上述过程 简化 下来,
我们 只是 需要 有一个 “Flag” 在 Redis 里 可以 供 多台 Server 的 线程间 同步协作 即可 。
严格的讲, 在 负载均衡 (集群), 即 多台 Server 的 情形下 才需要使用 Redis (分布式缓存) ,
如果 是 单台 Server , 则 使用 进程内 的 变量 来 作为 “Flag” Lock 即可 。
此时, 情况 则 退化为 进程内 多线程 之间的 同步协作 。
同时, 严格的讲, Redis 只需要提供一个 “Flag”, 或者说, Redis 只需要提供一个 锁机制 ,
并不需要 将 具体的 业务数据(对象) 保存 到 Redis,
进行 一笔交易 时, 不需要 到 Redis 查找 业务对象(比如 订单), 如果查不到再到 数据库 查, 更新时 先更新 Redis, 再更新 数据库 ,
没有必要这样 。
Redis 只要提供 “Flag” Lock 来 确保 顺序进入(同步协作), 具体的操作直接 读写 数据库 即可 。
所以, Redis 的 真正意义 在于 共享内存, 而不是 数据缓存 。
可以看看我昨天写的 《论 业务系统 架构 的 简化 (二) 用 关系数据库 作 缓存》 https://www.cnblogs.com/KSongKing/p/9928412.html
除了 锁, 事务 还有 另一方面, 数据完整性 。
比如, 更新 A, B, C 三张表, A, B 成功, C 失败, 于是事务会回滚, A, B 恢复原来的数据 。
要实现 数据完整性, 需要 表锁定 和 事务日志(这会带来 性能消耗),
可见,
数据完整性 同样也会成为 大并发 的 瓶颈 。
所以,我们这里 提出 一个 “乐观事务” 概念,
即 对于 每次交易, 都是 Insert , 而不会 反复 的 去 Update 。
假如一个交易 要 更新 3 个表, A 表 为 主表, B, C 表通过 A 表 的 ID 关联,
那么, 这个交易 对 A,B,C 3 个表都是 Insert 操作, 在 最后 事务成功 时 将 A 表里的 “生效” 栏位 更新 为 “Y”,
以此 表示 事务成功 。
显然, 这种做法 并不是对 所有场合 都适用, 它会让一些 小场景 变得麻烦 。
但是, 对于 前端 海量 用户 海量 并发 的 场景, 可以使用 这种做法 。
P : 我们大概可以把 每秒 100万 ~ 1000万 的 交易量 称为 “海量”, 把 每秒 1000万 以上 的 交易量 称为 “天量” 。
Redis 锁 + 乐观事务 = 新时代事务
我们来看一下 新时代事务 处理 3 个场景 :
1 订单(交易)
2 秒杀
3 商品库存计数
1 订单(交易),
用 Redis 锁 来 锁定, 用 乐观事务 执行 更新数据, 具体的 大家 自己想象 吧
2 秒杀
用 Redis 存一个 对象 记录 被 哪个 用户秒杀, 同时 加上 Redis 锁, 这样 用户 就可以 顺序 的 获取这个对象,
第一个获得这个对象的用户 就 秒杀 成功, 并更新这个 对象 的 状态 表示 秒杀成功 。
3 商品库存计数
同 Redis 存一个 对象 记录 库存量, 用户将 商品 放入 购物车 则 对象.库存量 - 1, 用户将 商品 从 购物车 删除 则 对象.库存量 + 1 ,
通过 对象锁 来 确保 用户顺序 获取对象 查看 和 更新 库存量 。
可以看看我前几天写的 《一个类似 Twitter 雪花算法 的 连续序号 ID 产生器 SeqIDGenerator》 https://www.cnblogs.com/KSongKing/p/9918412.html
通常, 一个实体 会 对应一张表,
我们以 订单 为例,
一笔 订单 对应 订单表 里的 一笔资料,
订单表 会有一张 对应的 订单_Trans 表, 用来记录 发生 在 订单 上的 乐观事务,
订单_Trans 表 会有一个 ID , 表示 Transaction ID ,
订单_Trans 表 同时还包含 订单 需要更新 的 栏位,
这样, 发生 一次 事务 时, 会向 订单_Trans 表 insert 一笔资料, 栏位 的 值 是 订单 本次 更新的 栏位 的 值,
事务 成功 后, 会将 订单 表 里的 “trans” 栏位 更新为 这次 事务 的 ID, 即 订单_Trans 表 的 ID ,
这样, 通过 订单.Trans = 订单_Trans.ID 关联, 可以查询到 订单 在 本次 事务 更新后的 栏位 的 值 。
一笔订单 在 订单_Trans 表 中可以对应 多笔 事务记录, 这些 事务记录, 有成功的, 也有不成功的 。
乐观事务 的 关键 在于 最后只能 更新 一张表 的 (一个)栏位 来 决定 事务是否成功,
如果要 更新 多个 表, 那又 回到 传统事务 了 。
所以, 这就看 针对性 的 设计 。
对于 淘宝 天猫 这样的 海量购物, 应该设计为 单项递增数据 的 架构, 也就是 只 insert , 不 update ,
但问题是 如果 一个 交易 里 要 insert 多个 表 呢 ?
也许可以用 乐观事务 A 表 关联 B 表, B 表 关联 C 表, ……
这样只需要 最后 更新 A 表里的一个 生效 栏位 , 就可以 表示 事务 是否成功 。
因为 可以 根据 A 表 关联 到 B 表 , B 表 关联 到 C 表 ,
或者有一个 Trans 表, 通过 Trans 表 的 ID (Trans ID) 来 关联 A, B, C 表 ,
这样可以 查询出 某一个 事务(Trans ID) 在 A, B, C 表 里 insert 的 资料,
然鹅 。
不过 说不定 这种方法 真的 有人在用 喔 ~!
数据完整性 最好 还有由 数据库 来实现, 这才是合理的 。
关键在于,
数据库 应该使用 行锁定 来 实现 数据完整性 。
就是说, 我们应该让 数据库 用 行锁定 来 执行 事务 。
淘宝 天猫 应该 自己 已经对 数据库 做过这种 优化了 。
也就是说, 淘宝 天猫 的 数据库 的 事务 是用 行锁定 的 方式 执行的 ,
当然, 这只是我的 猜测, 啊哈哈哈哈 。
Redis 锁定 + 数据库 行锁定 事务 (行级事务) + 数据库 使用 固态硬盘
这样 来 应对 大并发, 你觉得呢 ?