微信红包数据架构演变

PPT主题:微信红包数据架构演变
嘉宾：莫晓东有关资金安全,所以需要事务1.继续使用MySQL• MySQL支持事物，满足一致性要求。• 结构化存储，紧凑、连续。• 支持多索引。• 部署简单，工具支持。• 团队技术积累。• 设备改进。• 测试先行，实践是检验真理的第一标准。2.性能优化• 业务最终一致性，cap、base• 允许丢失和对账、异步达成。• 多层Cache。• 定制列表服务，下单前验证预订单。• 接入层数据cache，标记红包抢状态。• 部署优化。• 多实例，交错部署。• MySQL参数优化。• 系统层参数优化。• 数据优化。• Sharding，水平拆分。• 数据冗余，维度拆分。• 数据预生成，摇一摇红包预先导入。• 字段冗余，减少访问次数。• 默认字符集从utf8改latin1。3.有损服务、柔性可用、大系统小做• 有损服务:通过精心拆分产品流程，选择性牺牲一部分数据一致性和完整性从而保证核心功能绝大多数运行。核心功能是摇，拆，发。其它模块异常立即降级防止引起雪崩。• 过载保护，层层过滤、快速拒绝，把千万级别的请求减少到万级，减少DB负载。• 异步处理，耗时最长的入账操作，直接跳过，异步处理。• 柔性策略，关闭不重要的功能模块，比如查看收发历史、关闭祝福语。• 资源隔离，拆分红包DB为50个Set，出现故障只影响1/50。• 大系统小做，功能单一。逻辑层需要减少模块耦合，存储层也需要多源。• 故障处理，如果DB故障直接替换空白机器，未领取的红包锁定退款。4.红包野蛮生长-问题来了• 红包使用量急剧增长。• 拆事务性能瓶颈，高峰抖动。• 主从同步压力，对账不及时。• 存储容量压力，设备已缩容。• 需要进行业务重构。• 运维和开发处于高负荷状态。• 先应付眼前。5.解决问题:第一阶段，争取时间• 存储容量不足。• 使用InnoDB压缩格式，为冷热分离争取时间 。• 压缩率订单库44%，用户库57%。• 可接受的性能下降10-15%。• 性能问题。• 梳理主机SQL，索引优化、语句优化、请求精简。• 高峰期抖动，优化请求时间分布。• 新特性如线程池，4k page。• 主从同步延时。• 优化从机SQL。• 升级 Percona 5.5，多库同步。6.解决问题:第二阶段，冷热分离• 分离依据 。• 分析数据访问情况占比， 实测订单3天内，访问占比98.9%。• 优化目标。• 提高性能，减少现网库表数据量。• 节省成本，历史数据使用低成本大容量设备。• 历史库方案。• 按日分表，proxy路由请求。低峰时段搬迁数据，现网只保留7天。• 改善性能，从raid10+tokudb迁移到NoRaid+myisam，解决迁移问题和优化查询性能。暂时解决问题，脱离容量问题，性能稳定性增加。7.解决问题:第三阶段，必须重构• 表空间回收困难，现网库删除慢，历史库存储过大。• 字段过冗余，如果按每月约翻倍的速度增长，到年底是很惊人的。• 假设到年底还有6个月，如果2^6=64倍，那到2月份过年2^8=256倍。• 目前大约占了20T历史数据，如果几十几百倍，机器数量，业务成本无法承受。• 性能同样需要优化，拆红包单组DB拆峰值仅仅2000+，预计春节10w峰值，也无法完成任务。• 红包系统的性能瓶颈在拆事务上。
8.精简和拆分-容量比想象中更宝贵，按字节计算需求• 库表重新设计，字段缩减，去冗余。• 冗余字段精简。• 单号精简。• 字段类型精简。• 按天分表，循环使用。• 确保数据单表数据不会无限增长。• 用truncate代替delete清理。• 垂直分表力度更细。• 小表性能更佳。• 主键从单号修改为自增字段。• 自增主键减少体积，加速插入速度。• 不同的内容，不同的存储。• 有些内容使用kv更适合。• 用户维度迁入列表服务。• 扩散读和更依赖cache。• 个人红包和企业红包分离。• 企业红包特有字段去除。8.性能优化-异步和cache• 事物优化。– 事物语句精简和优化。– 入账分布式事务。– 提高并发度，请求排队机制。• 异步化。– 异步入账。– 异步用户信息。– 异步补拆，异步入账。• 语句优化。• 不查不需要的字段。• 非核心查询移到从机。• 大操作合并查询。• 先查cache。• 通过cache判断能不能抢。• 缓存常查询的内容。9.优化效果• 单表行数：• 千万级别到十万级别。• 拆性能：• 2000/s到6000/s+。• QPS：• 1.5w到6w。• 为业务快速成长排除了性能瓶颈：• 以去年春晚的2倍设备量，支撑今年春晚10倍的处理能力，容量上节省了数百台设备的成本。• 元旦实例验证，超过去年春节的量，单机负载小于20%。 10.还存在问题• 红包系统只部署深圳。• 跨城流量高延时。• 深圳机架位不足。• DB宕机后的数据安全• 主备切换风险：主备延时，数据不一致。• 切换后，数据写脏。• 资金风险。11.春晚准备工作-南北分布• 挑战。– 就近接入。– 城域容灾。• 南北分布设计。– 系统切分，相互独立。– 流量可调控。– 相互容灾。• 收益。– 故障恢复。– 流量均衡。– 降低时耗。12.2016年新架构• 异地多IDC部署。• 上海深圳南北分布。• 三园区部署。• 层级结构。• 纵向分层。• 异步结构。• 多set结构。**以上内容均来源于SDCC2016大会PPT**

微信红包数据架构演变相关推荐

PHP实现微信随机红包算法和微信红包的架构设计简介
微信红包的架构设计简介: 原文:https://www.zybuluo.com/yulin718/note/93148 @来源于QCon某高可用架构群整理,整理朱玉华. 背景:有某个朋友在朋友圈咨询微 ...
微信红包系统架构的设计和优化分享
微信红包系统架构的设计和优化分享编者按:经过2014年一年的酝酿,2015微信红包总量创下历史新高,峰值1400万次/秒,8.1亿次每分钟,微信红包收发达10.1亿次,系统整体运行平稳, 在这里我分 ...
情人节微信红包数据公布，你离海王与海后有多远...
情人节微信红包数据报告原文:2月14日,情人节,微信可以发520红包上海人最浪漫也最幸福(仪式感这玩意儿该有还是得有!) 单个用户收到520红包的最多超200个单个用户发出520红包的最多超150 ...
关于微信红包的架构思考
关于微信红包的架构思考微信红包的架构实现是前段时间技术圈里很热门的一个话题,这是一个非常典型的大访问高并发场景.至于如何实现,答案并不是唯一的,对这个问题的思考其实反映了工程师的架构设计功底.所以我 ...
微信红包技术架构，防外挂贼牛逼！（附胶片下载）
公众号后台回复 "微信红包架构" 下载该胶片参考:https://www.open-open.com/lib/view/open1427943866100.htmlhttp:// ...
我分析了上万个微信红包数据，得到了这些发现（附数据集）
引子笔者在2015年7月创建了一个以分享滴滴打车红包为主的微信群聊,创建的本意是为了方便大家在分享红包时不打扰别人,在乘车需要红包时能方便地领到红包.随着群人数和分享红包种类的增加,该群已成为一个各 ...
微信红包的架构设计简介
参考:https://www.zybuluo.com/yulin718/note/93148 http://coderroc.com/article/%E6%95%B0%E5%AD%A6%E5%92% ...
高并发资金交易系统设计方案—百亿双十一、微信红包背后的技术架构
21CTO社区导读 : 今天带来的是一个长篇文章.主要讲解高可用的互联网交易系统架构,包括双十一.支付宝&微博红包技术架构,以及微信红包的技术架构,希望能给各位提供价值. 概述话说每逢双十一 ...
微信红包随机数字_微信红包随机算法转载
php固定红包 + 随机红包算法 1 需求 CleverCode最近接到一个需求,需要写一个固定红包 + 随机红包算法. 1 固定红包就是每个红包金额一样,有多少个就发多少个固定红包金额就行. 2 随 ...

微信红包数据架构演变

微信红包数据架构演变相关推荐

最新文章

热门文章