乐视秒杀:每秒十万笔交易的数据架构解读
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 随着乐视硬件抢购的不断升级,乐视集团支付面临的请求压力百倍乃至千倍的暴增。作为商品购买的最后一环,保证用户快速稳定地完成支付尤为重要。所以在2015年11月,我们对整个支付系统进行了全面的架构升级,使之具备了每秒稳定处理10万订单的能力。为乐视生态各种形式的抢购秒杀活动提供了强有力的支撑。 一. 分库分表 在redis,memcached等缓存系统盛行的互联网时代,构建一个支撑每秒十万只读的系统并不复杂,无非是通过一致性哈希扩展缓存节点,水平扩展web服务器等。支付系统要处理每秒十万笔订单,需要的是每秒数十万的数据库更新操作(insert加update),这在任何一个独立数据库上都是不可能完成的任务,所以我们首先要做的是对订单表(简称order)进行分库与分表。 在进行数据库操作时,一般都会有用户ID(简称uid)字段,所以我们选择以uid进行分库分表。 分库策略我们选择了“二叉树分库”,所谓“二叉树分库”指的是:我们在进行数据库扩容时,都是以2的倍数进行扩容。比如:1台扩容到2台,2台扩容到4台,4台扩容到8台,以此类推。这种分库方式的好处是,我们在进行扩容时,只需DBA进行表级的数据同步,而不需要自己写脚本进行行级数据同步。 光是有分库是不够的,经过持续压力测试我们发现,在同一数据库中