《开发大牛实战经验：千万级并发下的推送系统建设策略解析》由会员分享，可在线阅读，更多相关《开发大牛实战经验：千万级并发下的推送系统建设策略解析（32页珍藏版）》请在金锄头文库上搜索。
1、千万级并发下的 推送系统建设策略解析叶新江/Anson Ye个推 个信互动AgendaPart 1. 推送系统总体要求Part 2. 面临的主要挑战和解决方案Part 3. 小团队打造大平台的实施策略Part 1 推送系统总体要求One Push Can Change E推送 = 通知 + 消息推送不能仅仅是通知， 而更需要突出消息属性 集中展示内容预览消息管理推送的目的：消息价值 最大化推送是什么？为甚么需要它？周知的推送平台均偏重基础能力、存在痛点！移动运营商时代的推送诉求SMS 推送时代被证明了推送的价值 但是： - 内容不够丰富- 大小限制- 无法满足端对端的完成业务链- 被滥用移动互
2、联时代的推送诉求- 更低成本更高效率- 展示的内容丰富，有声有色有视频- 智能判断内容对应的应用，智能下载安 装- 和应用能互动, 能促进应用的活跃- 对用户分段，针对性要强- 不要骚扰用户- 用户具有管理权力理想的推送系统不仅仅是一个具备推送能力的平台，更是一个为满足整个生态 发展，加强互动和协作的服务需要具备的基因- 支持大规模高并发（千万级） - 支持亿级用户规模 - 至少 99.9 可用性 - 网络不稳定环境下的生存力 - 低耗电、低流量下的客户侧控制 - 开发集成 - 运营集成 - 满足生态系统各角色需求的接入和控制Part 2 面临的主要挑战和解决方案移动推送需要面对的主要技术挑战
3、推送方式选择- Pull 方式优点：由客户端进行控制，服务端开发相对简单可以使用通用的 http client/server缺点：无论是否有内容，均需要消耗流量适合场景：比较适合数据变化比较快，实时要求不高的场合 频率的选择是关键推送方式选择- PUSH 方式优点：由客户端和服务端均可以进行控制实时性较高缺点：服务端开发复杂，需要解决大并发连接的问题适合场景：比较适合数据不是经常变化或者实时要求比较高的场合 可选择技术：BOSH/Comet长连接推送方式选择优先采用 Push+长连接方式* 可以提供高实时性要求* 建立在解决省电省流量基础上* 有大并发同时连接系统的经验可根据应用特性配置使用类
4、 Pull 方式移动终端侧要求- 作为集成到应用的一个层，需要做到：Slim ： 苗条、小样Save power ： 省电Save traffic ： 省量Stable ： 稳定端侧 4S 要求和标准。端侧 4S 如何做到- Slim这个相对容易，消除无用或者重复的代码，控制图片 等资源的使用- Save power手机电源的续航能力比较差，所以要从各个细节去抠不要使用过多线程，可以采用类似ActiveObject 的方法用单线程 模拟多任务处理尽量少使用多个连接（采用连接复用、主从模式）减少不必要的计算（通过 profiler 等工具来看哪些最好资源等)要摒除编写一般 Java 程序的习惯同
5、时要防止 CPU 在需要的时候休眠（使用 PM WakeLock 和 AlarmManager)端侧 4S 如何做到- Save traffic协议选择 (XMPP 还是私有协议？） XMPP: 开放、跨平台、分布式、安全；但是在窄带网络以及易断网络中，不一定是最好的选择 私有协议：不开放、无法互通、安全策略需要自己考虑；但是可以定制、节省流量心跳频率的控制，以实际设备网络、CPU 休眠时间作为主要依据数据压缩数据尽量Bundle传输断点续传有 WiFi 就优先使用 Wifi云端代理（这个目前使用第三方服务）- Stable独立的进程， 尽量不影响应用本身Android Bind/AIDL 机
6、制端侧另外需要的引擎- 内建的 Content Render Engine (CRE)布局内容抓取Text, Image, Web View, Video- 内建的 Action Chain Engine (ACE)把一系列的动作形成相关的数据链Action 类型可以是： - 消息提示、显示- 消息透传- 跳转到 browser- 启动应用- 下载应用- 激活应用适应生态的云端云端需要的基础部件框架化、组件化、插件化：u 配置管理 u 群集 （负载均衡、容错、动态伸缩） u 流控 u 服务管理（注册、寻址） u 依赖管理 u 灰度控制 u 分布数据操作 u 大数据处理 u 监控与告警一个可以参
7、考的系统架构单实例并发处理能力 50万 吞吐量较v1 * 10 倍 动态集群形成（处理&数据单元） 较灵活的可扩展数据层 集中配置管理 灰度控制支持 初步大数据处理框架 业务运营框架具备云端的几个关键点解析- 大并发长下的技术要点尽量减少应用内存的footprint. 高效使用内存(pre-alloc mem pool, thread-local-mem pool)选择合适 OS 和 语言组合如果是 Java, NIO 是必须的.NIO 事件处理模式的选择如果是 Java, JVM 的调优也是关键 （Heap size, GC etc)注意一些已知的问题（譬如 JDK 7 之前的 Select
8、 Spin）内核调优（特别是网络参数方面） 云端的几个关键点解析- 异步系统的痛并快乐要增加系统的吞吐量，系统内部需要异步调用异步会使复杂度增加，但是在很多时候是值得的需要内部有统一的通讯框架(支持同步、异步、回调；广播、随 机、轮询等机制）- 去状态化，全 cluster状态化会导致资源的 affinity, 在 scalability 方面有较大影响。 易于水平扩展。状态转移到公用设置上（如分布缓存或者 DB 中 ，但是必须考虑故障时的转移效率和成本）各个组件均 cluster 化，随时扩展容量，系统自调整能力强。云端的几个关键点解析- 分布式组件分布式缓存自动平衡、自动复制、容错或者应用
9、自行根据需要来进行功能补充（例如双写、多写等）分布式数据库存储层自动分发、路由设置、逻辑上去除不同数据库的差异。- 数据分析和 BI大数据量处理 （Hadoop, Hive， infoBright w/ MySQL等 )如果成本或者资源不允许，可以租用公共云服务云端的几个关键点解析- 应用域隔离/灰度控制不同的应用有时候需要逻辑上进行隔离不同的版本很多时候需要滚动升级，只能在不同的时 间进行升级，而且在可用性要求下必须动态调整实现策略： 整合到 cluster 方案中，使用高可靠的协 作组建（zk) 来进行组件配置及状态管理 云端的几个关键点解析- 保证推送到达率目标 99% 有效用户到达率推
10、送时间 3s (端对端）策略：用户冷热状态内存缓存在线用户：使用最接近端侧的传输到达机制离线用户： 冷热用户分层数据存储分层精细化的要求- 运营与服务驱动 - 业务制作可视化 - 业务种类细分（系统需适应性演进） - 最终用户种类细分（系统需适应性演进） - 合作者种类细分（系统需适应性演进） - 不同合作模式下的系统版本分离（SaaS, Out-of- Box 产品等）Part 3 小团队打造大平台的策略小团队，所以必须灵活敏捷的流程及持续改进：- SCRUM- CI- DevOPS系统逐步组件化在满足业务快速实现的前提下 逐步把系统框架化、组件化 形成公用设施：- 通讯框架- 集群框架- 数据存储框架- 配置框架- 插件框架- 监控框架/插件我们的目标个推 - 中国最专业的独立 推送平台及服务提供商http:/www.iGThanks
