支付宝打赏 
微信打赏 
字节
系统设计
抖音支付十万级TPS流量发券实践
文章内容：抖音支付十万级TPS流量发券实践
文章总结：
异步发券：
- 提升接口响应速度
双层本地队列：
- 提升处理能力，平滑流量
库存扣减：
- 合并扣减，本地内存校验库存信息
优雅退出：
- 为了内存中的数据不丢失，需要能够感知到应用退出的信号，在应用退出前将内存中的数据处理掉
兜底补偿：
- 异常情况引起的应用退出，无法执行优雅退出，增加兜底补偿机制
库存防超卖：
- 发券失败，回滚
Redis库存
抖音视频红包系统设计与实现
文章内容：抖音视频红包系统设计与实现
文章总结：
模块拆分：
- 红包网关服务，红包核心服务，红包查询服务，红包异步服务，红包基础服务，红包对账服务
- 功能内聚，每个系统只处理一个任务
红包领取方案：
- 红包
Redis限流- 内存排队
- 转账异步化
多重机制保证状态机的推进
服务Set化：
- 服务
Server和对应的存储划分为一个单独的Set
10万级QPS大流量、高并发优惠券系统
文章内容：10万级QPS大流量、高并发优惠券系统
文章总结：
券过期:
RocketMQ实现：延时消息有最大限制，过期消息循环处理，直到卡券过期热点库存问题：
- 库存拆分：扣减库存时，也扣减相应的子库存
券模板信息缓存到本地内存
大流量奖励系统入账及展示的设计与实现
文章内容：大流量奖励系统入账及展示的设计与实现
文章总结：
支持多端奖励数据互通：
- 中台提供的唯一ID基础上，实现支持多端奖励入账
热
Key的读取和写入：
- 方案一：拆分多个
Key，用本地缓存兜底- 方案二：
- 写场景：通过本地缓存进行合并写请求进行原子性累加
- 读场景：返回本地缓存的值
大流量集中发券：
- 使用
Redis计数，单Key会存在热Key问题，需要拆分Key来解决- 少发问题:
- 上游继续重试发券会多消耗库存少发
- 预估库存基础上加了5%的量级来缓解超时带来的少发问题
设计方案
高峰值奖励发放技术方案
文章内容：高峰值奖励发放技术方案
文章总结：
奖励SDK设计
大流量活动下钱包提现方案的设计与实现
文章内容：大流量活动下钱包提现方案的设计与实现
文章总结：
延时放量:
- 分批次放开提现降低用户提现的并发
异步出款:
- MQ消费提现订单的现金出款
定时任务进行补单推进提现状态
订单幂等:
- 针对
OrderID做幂等性控制，每个OrderID只有一笔扣款操作对账校验：
- 准实时对账和天级对账进行资金的校验
京东
系统设计
日均千万订单的存储
文章内容：交易日均千万订单的存储架构设计与实践
文章总结：
个性化业务模型扩展性：
- 根据业务身份+业务类型+业务字段找到不同的数据模型以及数据扩展编码
单元化架构：
- 同一个用户的相关请求，只在一个机房内完成所有业务闭环，不再出现跨机房访问
线上问题
MySQL锁引发的线上问题
文章内容：MySQL锁引发的线上问题
文章总结：
避免短时间内存在对同一行数据的先更新再插入的并发操作
腾讯
系统设计
微信服务稳定性保证
文章内容：月活12.8亿信服务稳定性保证
文章总结：
监控服务过载
过载保护策略：
- 按照业务优先级处理请求
- 设置用户优先级
- 支持自适应优先级调整
阿里
设计方案
订单场景下的超时处理方案
文章内容：订单场景下的超时处理方案
文章总结：
JDK队列方案：
- 内存占用大，处理效率低，不适合订单量大的场景
RabbitMQ延时消息方案：
- 使用复杂且不灵活
RocketMQ定时消息方案：
- 成本太高，同一个时刻大量消息影响精度
Redis过期监听方案：
- 不可靠，有稳定性问题
定时任务分布式批处理方案（推荐）：
- 基于定时任务分布式批处理的超时中心来做订单超时处理
超时精度比较高，超时时间在24小时内，且不会有峰值压力的场景：
- 推荐使用RocketMQ的定时消息解决方案
电商业务，许多订单超时场景都在24小时以上，对于超时精度没那么敏感，并且有海量订单需要批处理：
- 推荐使用基于定时任务的跑批解决方案
业务团队如何正确发MQ消息
文章内容：业务团队如何正确发MQ消息
文章总结：
事务消息：
- 实现复杂，事务阻塞问题
消息表：
- 增加数据库写入和读取压力
- 业务操作的代码看起来很整洁