千万级并发下的推送系统建设解析

下载需要 8 金币 [ 金币充值 ]

服务器/托管费、人工审核、技术维护等都需要很多费用，请您支持深度开源的发展

下载PPT

PPT 内容

1. 千万级并发下的推送系统建设策略解析叶新江 @个推 @猪立叶-Anson
2. 目录123推送系统总体要求面临的主要挑战和解决方案小团队开发平台的策略
3. Part 1 推送系统总体要求 One Push Can Change Everything
4. 推送系统总体要求SMS 推送时代被证明了推送的价值 - 稳定、可靠 - 基本上终端无关 - 丰富的生态链但是： - 内容不够丰富 - 大小限制 - 无法满足端对端的完成业务链 - 被滥用移动运营商时代的推送诉求
5. 推送系统总体要求移动互联时代的推送诉求在享受了 SMS 推送的便利之上，希望附加: - 更低成本更高效率 - 展示的内容丰富，有声有色有视频 - 智能判断内容对应的应用，智能下载安装 - 和应用能互动, 能促进应用的活跃 - 对用户分段，针对性要强 - 不要骚扰用户 - 用户具有管理权力
6. 推送系统总体要求周知的推送平台均偏重基础能力、存在痛点！
7. 推送系统总体要求理想的推送系统不仅仅是一个具备推送能力的平台，更是一个为满足整个生态发展，加强互动和协作的服务 -- 为客户产生增值
8. 推送系统总体要求需要具备的基因支持大规模高并发（千万级）支持亿级用户规模至少 99% 的有效送达率至少 99.9 可用性网络不稳定环境下的生存力低耗电、低流量下的客户侧控制开发集成运营集成满足生态系统各角色需求的接入和控制
9. Part 2 面临的主要挑战和解决方案
10. 主要挑战和解决方案移动推送主要技术挑战
11. 主要挑战和解决方案推送方式选择Pull 方式优点：由客户端进行控制，服务端开发相对简单可以使用通用的 http client/server 缺点：无论是否有内容，均需要消耗流量频率的选择是关键 PUSH 方式优点：由客户端和服务端均可以进行控制实时性较高缺点：服务端开发复杂，需要解决大并发连接的问题
12. 主要挑战和解决方案我们对推送方式选择优先采用 Push+长连接方式 * 可以提供高实时性要求 * 建立在解决省电省流量基础上 * 有大并发同时连接系统的经验可根据应用特性配置使用类 Pull 方式
13. 主要挑战和解决方案移动终端侧要求作为集成到应用的一个层，需要做到： Slim ：苗条 Save power ：省电 Save traffic ：省量 Stable ：稳定端侧 4S 要求和标准。
14. 主要挑战和解决方案 - Save power 手机电源的续航能力比较差，所以要从各个细节去抠不要使用过多线程，可以采用类似ActiveObject 的方法用单线程模拟多任务处理尽量少使用多个连接（采用连接复用、主从模式）减少不必要的计算（通过 profiler 等工具来看哪些最好资源等) 要摒除编写一般 Java 程序的习惯，多考虑CPU/网络等操作带来的电源损耗。和 Save Traffic 也有很大关系
15. 主要挑战和解决方案Save traffic 协议选择 (XMPP 还是私有协议？） XMPP: 开放、跨平台、分布式、安全；但是在窄带网络以及易断网络中，不一定是最好的选择私有协议：不开放、无法互通、安全策略需要自己考虑；但是可以定制、节省流量心跳频率的控制，以实际设备网络、CPU 休眠时间作为主要依据数据压缩数据尽量Bundle传输断点续传有 WiFi 就优先使用 Wifi Stable 独立的进程，尽量不影响应用本身 Android Bind/AIDL 机制
16. 主要挑战和解决方案适应生态的云端
17. 主要挑战和解决方案框架化、组件化、插件化：配置管理群集（负载均衡、容错、动态伸缩）流控服务管理（注册、寻址）依赖管理灰度控制分布数据操作大数据处理监控与告警
18. 主要挑战和解决方案大并发长下的技术要点尽量减少应用内存的footprint. 高效使用内存(pre-alloc mem pool, thread-local-mem pool) 选择合适 OS 和语言组合如果是 Java, NIO 是必须的. NIO 事件处理模式的选择如果是 Java, JVM 的调优也是关键（Heap size, GC etc) 注意一些已知的问题（譬如 JDK 7 之前的 Select Spin）内核调优（特别是网络参数方面）
19. 主要挑战和解决方案 - 保证推送到达率目标 > 99% 有效用户到达率推送时间 < 3s (端对端）策略：用户冷热状态内存缓存在线用户：使用最接近端侧的传输到达机制离线用户：冷热用户分层数据存储分层加大吞吐能力（全链路交换实现）关键数据多种策略保证其可靠传递
20. 主要挑战和解决方案异步系统的痛并快乐要增加系统的吞吐量，系统内部需要异步调用异步会使复杂度增加，但是在很多时候是值得的需要内部有统一的通讯框架(支持同步、异步、回调；广播、随机、轮询等机制）去状态化，全 cluster 状态化会导致资源的 affinity, 在 scalability 方面有较大影响。易于水平扩展。状态转移到公用设置上（如分布缓存或者 DB 中，但是必须考虑故障时的转移效率和成本）各个组件均 cluster 化，随时扩展容量，系统自调整能力强。
21. 主要挑战和解决方案分布式组件分布式缓存自动平衡、自动复制、容错或者应用自行根据需要来进行功能补充（例如双写、多写等）分布式数据库存储层自动分发、路由设置、逻辑上去除不同数据库的差异。数据分析和 BI 大数据量处理（Hadoop, Hive， infoBright w/ MySQL等 ) 如果成本或者资源不允许，可以租用公共云服务
22. 主要挑战和解决方案 - 应用域隔离/灰度控制不同的应用有时候需要逻辑上进行隔离不同的版本很多时候需要滚动升级，只能在不同的时间进行升级，而且在可用性要求下必须动态调整实现策略：整合到 cluster 方案中，使用高可靠的协作组建（zk) 来进行组件配置及状态管理
23. 主要挑战和解决方案精细化要求运营与服务驱动各种运营数据，准实时要求业务制作可视化 Composer 模拟效果展示业务种类细分业务特性区分（高价值信息 vs 广告信息）业务等级授权最终用户种类细分合作者种类细分不同合作模式下的系统版本分离
24. Part 3 小团队打造大平台的策略
25. 小团队大平台小团队，所以必须灵活敏捷的流程及持续改进： - SCRUM - CI - DevOps
26. 小团队大平台在满足业务快速实现的前提下逐步把系统框架化、组件化形成公用设施： - 通讯框架 - 集群框架 - 数据存储框架 - 配置框架 - 插件框架 - 监控框架/插件
27. 我们的目标个推 - 中国最专业的独立推送平台及服务提供商http://www.iGetui.com 合作伙伴：新浪、百度、网龙等
28. 28http://www.iGetui.com

千万级并发下的推送系统建设解析

gtimehero

贡献于2013-01-04

千万级并发下的推送系统建设解析

PPT 内容

PPT 图集

相关PPT