腾讯亿级排行榜系统实践及挑战.docxVIP

腾讯亿级排行榜系统实践及挑战 排行榜满足了人的攀比、炫耀心理，几乎每个产品都会涉及。SNG增值产品部的QQ会员、QQ动漫、企鹅电竞、玩耍赛事等大量业务都对排行榜有猛烈需求，特殊是企鹅电竞等业务的进展壮大对我们排行榜系统提出了更多要求和挑战。在过去的一年中，排行榜系统从无到有，接入的业务从单一的QQ会员到企鹅电竞动漫等20几个各类业务，接入的排行榜数实现了从几个到数万的突破，单个排行榜用户数最大9000万, 排行榜存储集群活跃用户量数亿，而在这过程中，排行榜系统也遇到了以下挑战： 如何支持业务就近接入？低延时? 如何支撑数万乃至几十万级排行榜自动化申请调度？ 如何降低机器成本？选择合适存储引擎？ 如何避开各业务资源抢占，相互影响？ 接下来的各小节会具体争辩目前我们在实践中是如何处理这些挑战的。 二. 排行榜系统基本架构 在争辩我们如何处理面对的挑战之前，先简约了解下排行榜系统基本架构、以及业务是如何接入、使用排行榜系统的。排行榜系统基本架构如图三所示，当前的排行榜系统架构不是设计出来的，而是依据我们业务场景、需求、进展等不断演化，不断优化而构成，其次要由以下几个服务组成： 接入服务（无形态，供应访问修改排行榜数据的全部RPC接口给业务使用，如查询名次、topN等） 存储服务（无形态，主备部署，排行榜数据存储） APIServer服务（供应申请排行榜、业务接入、排行榜配相信息、存储机容量等接口） 调度服务（从存储机中筛选满足业务申请条件的存储机，并择优安排） Agent（上报存储机容量信息、存储服务监控数据等） ZooKeeper(排行榜路由数据存储、存储机容量数据存储等，为什么我们选择zookeeper将在第三部分说明) Mysql(业务接入信息、各排行榜配置、用户量、存储服务核心参数监控等存储) 业务接入排行榜系统时，首先会为每个业务安排一个ID，其次需要申请排行榜ID，业务排行榜server通过l5调用排行榜系统的接入服务，接入服务每个接口都包含业务ID、排行榜ID，接入服务通过业务ID、排行榜ID查询zookeeper猎取该业务排行榜ID的存储服务实例，最终通过存储服务API操作排行榜数据，前往结果给业务Server。 上面提到的L5是什么呢? L5(Load Balancer，5代指Level5，即99.999%的可用性)是一套兼具负载均衡和过载爱护的容错系统, 业务服务接入L5时，会安排一个标识（modid、cmdid），此标识映射若干业务服务器IP:PORT，业务机器需要部署L5 agent, l5最大的缺点是业务服务若要通过L5调用被调, 就必需修改代码，每次网络调用之前都需要通过L5 agent api猎取被调IP:PORT,调用结束之后上报调用延时、前往码等。 三. 如何支持业务就近接入？低延时? 因部门产品业务较多,服务部署区域也各异，有的业务部署在深圳地区、有的业务部署在上海地区。深圳、上海内网机房ping延时约30ms, 这么高的延时是部分业务无法容忍的，作为平台支撑方，我们也期望供应的各接口平均延时应在5ms内，所以要尽量避开跨城访问。 如何避开跨城访问呢? 当然是各区域自治，晚期因接入业务、排行榜数都较少,只要接入服务、存储服务机器是按地区部署的，排行榜路由数据存储只部署在深圳，排行榜路由也只会在没命中localcache的情况下才会跨城查询深圳的路由数据存储集群，当时延时也能满足业务需求, 因而我们并未完全支持业务就近接入。 但是后面随着各类业务快速接入、排行榜的快速添加，特殊是当localcache失效时，上海地区服务质量、延时波动较大，频繁告警，于是我们不得不推动各区域全面自治方案。 业务场景打算着我们选择什么存储方案来处理跨城访问导致的高延时问题。 简约分析下我们的业务场景(业务核心链路恳求): 存储的是什么数据? 数据量多大?? 路由、存储节点容量数据,估计几十万条,key、value长度较小（（当然也可以接受表结构存储） 读写比例? 读为主,极少量写(每分钟几个,申请排行榜时才会添加路由配置) CAP如何取舍? 尽量保证各区域数据全都性,不丢失数据，高可用性(如其中一节点宕机不影响服务读)，在消灭网络分区时（如深圳、上海网络中缀），集群少数成员一方(上海地区)，能够降级供应只读模式。 常用的开源处理方案，以及各方案的优势、不足如下: 结合以上各处理方案优缺点，再依据我们的业务场景需求，我们选择了zookeeper作为核心的路由、存储节点容量数据存储，然后我们还面临着深圳、上海各部署一套还是只部署一套的选择。若深圳、上海各部署一套，我们的方案是深圳集群为主写，主写成功后，write opration log(create/set)可以写入MQ，MQ需支持 at-least-once语义, 由