消息推送

前言后面介绍了一封传话聚合推送API的在线测试推送的步骤，能够实现一对一发送音讯。 然而咱们心愿实现：1. 群组订阅性能：例如我和我的好友一起退出通道后，只推送一次咱们两个人都能收到音讯。2. 多端揭示性能：例如我心愿同时推送到微信和钉钉，如果还能推送到飞书更好了。 一封传话这些性能全都反对，然而须要你到顶部导航栏 —— 通道治理 —— 推送通道页面去创立新的通道，这样就能给通道生成二维码，好友扫码当前就能退出通道。 首先你得有一个账号 无需注册，微信扫码登录后会跳转到推送通道治理页面，这时候点击“新增推送通道”按钮去创立一个微信推送通道，输出通道名称后点击保留。 下图是方才创立好的通道基本功能，间接点“详情”按钮跳转到通道详情页面。 通道码和测试性能都在下一个页面，咱们点击“详情”按钮跳转到详情页面。 一对多人推送原理实现原理：【一封传话】通过生成微信公众号场景二维码，能智能辨认关注过通道码的用户openid，当你向通道推送音讯的时候，一封传话会将音讯分发给关注过通道的用户。 而且，一封传话反对创立多个通道，随时启用/禁用通道实现开关性能。 上方有测试链接，右侧区域就是这个通道码了，邀请好友扫码关注。 好友扫码当前，他会主动呈现在左侧区域，通道创建人还能够移除他。 “点这里在线测试”跳转到测试页面，而后点击“发送测试”按钮。 此时，你和你的好友微信上应该收到了同一条推送内容。 点击“查看详情”，推送内容反对Markdown语法和根本的html语法渲染。 这就是一对多人推送的根本测试步骤，非常适合做网站布告订阅，如果有新的布告，扫码关注用户都能收到布告推送。如果有人订阅后心愿退订，能够间接在预览页面点击“勾销订阅”后不会再收到布告推送了。 扫码图片采纳的是活码： https://www.phprm.com/services/qr/c/1676044887/95v0yd5xowld复制永恒链接通过src间接援用图片（二维码每10天会主动刷新，无需截图保留）。通过API推送形式请参考：一行代码实现微信音讯推送 一对多端推送原理所谓一次推送多端揭示的意思就是说，一行API代码的申请，能够让微信、钉钉、飞书、邮箱同时收到音讯，这样简洁的API谁能不爱呢。 实现原理：【一封传话】反对创立“组合通道“类型的父通道，而后将具体的推送通道（微信推送、钉钉推送、飞书推送、邮件推送）的父通道批改为”组合通道“，进而实现一次推送，多端接管。 首先你得创立一个组合通道，输出名称后下拉框抉择组合通道 而后批改以前创立的微信通道将父通道指向组合通道后保留，同理将飞书推送通道的父通道也指向组合通道后关上组合通道详情页面。 关上组合通道的详情页面，你会发现子通道列表上面展现了组合通道下的具体推送通道。 目前组合通道下绑定的子通道个数没有下限（你能够绑定多个飞书群机器人或者多个钉钉群机器人哦）。 如果将来的某一天，咱们心愿可能不改任何代码的状况下也推送到钉钉，那就创立一个钉钉推送通道吧，而后将其父通道指向组合通道。 组合通道下当初有3个子通道，咱们进入到测试页面发送一条测试音讯： 这样就曾经实现了一次推送，多端揭示的需要了。最重要的一点就是，集成API到程序中时，记得用父通道码哦，同样通过API推送形式没有任何区别。一行代码实现微信音讯推送 到顶部导航栏——推送日志查问历史音讯推送记录 Tips：这里的理论推送工夫比触发工夫略晚，因为推送量很大，服务器每天会排队解决推送申请稍有提早（异步解决，咱们也在优化升高提早哦）。 另外，咱们能够拿着音讯ID到 一封传话聚合推送API文档 的发送后果查问区域查问推送和阅读数。 这就是一对多端的根本测试步骤，对于代码谨严要求的人，倡议应用组合通道将真正的推送通道给包装起来，后续降级保护都不须要改代码了。 Tips：挪动端默认全局启用组合通道（上图中只需同时勾选微信公众号、钉钉群机器人、飞书群机器人即可），没有任何多余操作，快来体验吧！ 点击拜访挪动端官网：https://www.phprm.com/push/h5/ 参考： https://segmentfault.com/a/1190000043417419 http://push.phprm.com/doc/#/p/send https://segmentfault.com/a/1190000043417394 一封传话官网

一封传话聚合推送各语言demo代码示例 前言查看一封传话的API文档的GET申请只需一行代码，在url上拼接head和body参数即可实现推送。这里针对body数据量较大的状况，给出各语言实现的demo代码。 Tips：以下代码中的trigger与API文档中的send等价，trigger在send根底上做了高级个性加强解决，能够参考：一封传话聚合推送高级个性API任何使用者都能够随便抉择调用任何一个API，在API的应用形式上没有差别。 PHP语言<?php// 通道码/口令码$channel_code = "4d2dac865118761a14d10d7d3afe7c35";$head = "测试题目";$body = "测试内容";$postdata = json_encode( array( 'head' => $head, 'body' => $body ) );$opts = array('http' => array( 'method' => 'POST', 'header' => 'Content-type: application/json', 'content' => $postdata ) );$context = stream_context_create($opts);$api_url = 'https://www.phprm.com/services/push/trigger/'.$channel_code;$result = file_get_contents($api_url, false, $context);echo $result;如果你更偏向于应用curl库, 齐全能够本人实现或者参考以下开源的三方库里的curl代码。 一些开源的三方库如果心愿应用业余推送库, 能够参考此开源我的项目, 【一封传话】聚合推送SDK曾经提交到Github和Gitee，通过composer能够间接装置SDK: Github: https://github.com/guanguans/notifyGitee: https://gitee.com/guanguans/notify提供博客零碎新注册用户、新评论揭示插件, 能够参考插件源码或者间接在本人的网站应用： WordPress插件: https://github.com/teakong/wordpress-tixing 或者 https://gitee.com/teakong/wordpress-tixingTypecho插件: https://gitee.com/teakong/wordpress-tixing 或者 https://gitee.com/teakong/TypechoTixing其余博客或网站插件: https://github.com/teakong/liuyan-weixin 或者 https://gitee.com/teakong/liuyan-weixinJAVA语言倡议应用Guava自带限流工具类, 例如10秒告警一次避免大量申请耗费你本人的服务器，如果应用redis分布式限流更好，这里还用到了Hutool工具包下的http申请类。 Hutool官网阐明文档: https://hutool.cn/docs/#/ 最新maven如下 ...

一封传话聚合推送高级个性API 前言上一次介绍了一封传话的API文档的次要推送API，次要用于实现疾速推送到微信、企业微信、钉钉、飞书、邮箱、自定义Webhook。集成该API后仅需1个必传参数，即可实现一次推送多端接管和一次推送多人接管性能。 在电脑端，咱们依照官网的创立、测试流程调用的API是send接口，可能满足绝大多数用户的需要。 在挪动端提供了更丰盛的配置界面，例如预设参数、执行周期抉择、音讯通道缺省配置主动填充，加强原有API接口后能够实现更加弱小的trigger接口，能够满足局部用户的高级需要。 上面是tigger的接口文档和send接口文档比拟后发现入参和出参简直没有区别，这里介绍次要trigger接口绝对于send接口加强后的高级个性： 发送揭示接口申请地址：https://www.phprm.com/service...申请URL上的xxxxxxxxxxxxxxxx, 是您创立揭示的口令码申请形式：GET倡议对参数进行urlencode编码, POST形式申请头,Content-Type: application/json参数名称是否必填默认值阐明head否挪动端可预设音讯题目, 长度200以内body否挪动端可预设音讯内容, 长度50000以内, 反对markdown格局, 请参考markdown语法delayMilliseconds否0提早推送毫秒数, 不倡议传递, 如需传递最大不超过45天url否挪动端可预设不填将应用官网网址进行预览, 填写后将跳转到自定义网址, 例如: https://weibo.comGET申请形式样例： https://www.phprm.com/services/push/trigger/xxxxxxxxxxxxxxxx?head=默认题目&body=默认内容音讯推送接口响应内容样例： { "code": 0, "message": "申请胜利", "data": { "messageIdList": [ "1195026147680247809" ] }}trigger具备send所有个性，减少了前置预处理和后置解决。思考到trigger接口执行步骤多会耗费更多的性能，而且会略微减少API调用耗时。您能够参考是否应用以下高级个性，再决定应用send接口还是trigger接口。 高级个性预置题目head、预置注释body，无需传递任何参数即可实现推送；预置题目head、预置注释body反对{{变量}}实现参数映射, 预设{{title}}和{{content}}当前trigger API将通过?title=题目&content=注释调用形式；预置题目head和预置注释body的变量属性层级反对10层以内参数映射，例如网页更新揭示的{{data.title}}和{{data.text}}属于第2层；新增触发形式：口令触发(send接口也反对)、定时触发(quartz表达式或者按年月日循环执行)；新增触发一次个性, 容许执行一次推送后主动暂停揭示状态；能够这么了解，send接口是一个高性能音讯推送接口，trigger做一层包装后性能更弱小。 特地是通过预置{{参数}}映射其余开源软件参数, 如果您的路由器或者某些软件的webhook参数无奈批改，能够试试trigger。实践上绝大多数的软件的webhook都能适配，目前已适配Granfna告警、网页更新揭示、Server酱、Gitee、Github，欢送到挪动端体验。 如果您没有用到以上高级个性能够间接应用send接口，这样http申请提早会更小一些。 参考： 一行代码实现微信音讯推送 一封传话推送工具API文档 http://push.phprm.com/api.html

在全球化的浪潮之下，越来越多的国内开发者抉择“乘风出海”。音讯推送作为APP连贯用户的有效途径，成为开发者进军海内市场的刚需。但因为海内外网络环境、利用生态等的差别，APP在海内推送的过程中，也面临着音讯通道建设、海内用户精密经营、数据安全合规等方面的诸多挑战。为此，个推推出海内音讯推送解决方案，帮忙APP高效整合海内音讯通道，构建智能、精密、高效的用户触达体系，促成APP海内业务快速增长。  多链路触达体系，晋升用户触达用户触达通道，是APP与用户高效沟通的“桥梁”。但在APP构建海内音讯通道的过程中，也存在着不少“隐痛”：一方面，自建通道或逐个对接各厂商海内通道，不仅费时费力且老本居高不下；另一方面，面对寰球简单的网络环境，若APP只采纳FCM或APNs的零碎通道，又会遇到音讯送达率的瓶颈。 个推为APP构建了海内多链路触达体系，助其突破用户触达的壁垒。基于APP海内推送需要，个推不仅提供自有在线渠道，无缝对接FCM、APNs零碎通道，还高效整合了小米、华为、光荣、魅族、 OPPO等厂商推送能力。APP只需一次集成即可接入多厂商海内推送服务，实现在线、离线推送，保障音讯稳固、高效送达。 同时，个推还反对国内短信推送，帮忙APP进一步拓宽海内用户触达渠道，全面晋升音讯达到率。 依靠海内多链路触达体系，APP不仅能够自选音讯下发通道触达海内用户，还能通过音讯并发、散发、补发等形式，进步音讯达到率。此外，个推还提供离线音讯库、超长音讯主动截短、厂商推送余量查问治理等能力，反对各阶段、各渠道推送数据后效剖析，帮忙APP科学管理渠道资源，以更低的老本实现用户触达效率的全面降级。  多样化推送策略，晋升用户转化音讯点击率与经营转化成果密不可分。基于海内推送场景，个推反对丰盛的音讯展现款式以及亮屏推送、A/B Test、音讯分组、定时推送等音讯经营工具，帮忙APP精细化触达海内指标人群，进步音讯点击转化率，晋升用户沉闷与留存。 保障数据合规，护航APP“扬帆出海数据安全是寰球关注的焦点，也是APP出海的“必修课”。为全方位护航APP扬帆出海，个推构建了全球化的云服务集群，实现寰球服务器多节点部署，保障海内推送的稳定性。 此外，个推还提供分层权限治理、鉴权体系、日志监控、敏感内容审核过滤等多重爱护机制，帮忙APP升高经营危险，全方位保障数据安全、系统安全和内容平安。 深耕挪动开发畛域十余年，个推通过平安、稳固、牢靠的产品及服务博得了寰球开发者的信赖。大航海时代，个推还将继续翻新产品和技术服务，帮忙更多开发者晋升增长效率、开辟海内市场幅员。 

1、引言本文内容来自vivo互联网服务器团队李青鑫在“2021 vivo开发者大会”现场的演讲内容整顿而成（现场演讲稿可从本文末附件中下载）。本文将要分享的是手机厂商vivo的零碎级推送平台在架构设计上的技术实际和总结。这也是目前为止首次由手机厂商分享的自建零碎级推送平台的技术细节，咱们也得以借此机会一窥厂商ROOM级推送通道的技术水准。 学习交换： 挪动端IM开发入门文章：《新手入门一篇就够：从零开发挪动端IM》开源IM框架源码：https://github.com/JackJiang2...（备用地址点此）（本文已同步公布于：http://www.52im.net/thread-40...） 2、对于作者李青鑫，vivo互联网服务器团队架构师。 3、为什么须要音讯推送音讯推送对于挪动端APP来说，是很常见的业务特色，比方新闻APP中的最新资讯、社交利用中的零碎告诉、IM即时通讯利用的离线聊天音讯等等。能够说，没有音讯推送能力，APP就失去了实时触达的能力，对于一个利用来说，它对用户的“粘性”将大大降落。而对于用户来说，信息实时获取的能力也将大大降低，用户体验也将大幅降落。 4、音讯推送的技术阻碍以咱们日常最常见的IM利用来说，离线音讯的推送是必备能力。但随着Android零碎的一直降级，离线推送曾经不单单是一个后盾服务加长连贯那么天经地义了。 对于晚期的Android零碎来说，想要实现IM的离线音讯推送并不艰难，搞个后盾服务再加上socket长连贯就算是齐活了。但随着Android零碎的降级，针对后盾过程和网络服务限度一直加码，为了持续实现离线音讯的推送，开发者们不得不跟零碎斗志斗勇，搞出了各种保活黑科技，比方：Android4.0之后的双过程守护、Android6.0及之后的防杀复活术、以及倒退到起初的腾讯TIM过程永生技术，一时间群魔乱舞、无比风骚（有趣味的同学，能够读读《Android过程永生技术终极揭秘：过程被杀底层原理、APP应答被杀技巧》这篇针对所有保活黑科技的总结性文章）。 随着Andriod 9.0的到来，根本从零碎上堵死了各种保活黑科技的生路（详见《Android P正式版行将到来：后盾利用保活、音讯推送的真正噩梦》），各Android厂商的ROOM零碎级推送通道也应运而生——华为推送、小米推送、魅族推送、OPPO推送、vivo推送，一时间从用户的噩梦（保活黑科技对用户困扰很大）变成了开发者的恶梦并继续至今（想要做好IM离线推送，现在的IM开发者们不得不一家家对接各手机厂商的离线推送，你说烦不烦）。 也别跟我说为什么不必Android官网的FCM服务（在国内这链接你能关上算我输，至于为什么，你懂的。。。），也别我跟提那个对立推送联盟（4、5年过来了，看样子还要持续等上来）。 于是，为了持续搞定离线音讯推送，IM的开发者们目前只有两条路可选： 1）举白旗向零碎投降，放弃保活黑科技，间接疏导用户手动加白名单（详见《Android保活从入门到放弃：乖乖疏导用户加白名单吧》）；2）一家一家对接各厂商的零碎级推送通道（华为、小米、魅族、OPPO、vivo，喜剧的是，有些小众厂商并没自建推送的能力）。 随着Android零碎对于开发者保活黑科技的“堵”，手机厂商们搞出自家的零碎级推送通道来“疏”，也算是天经地义。而这些厂商之中，vivo的零碎级推送通道呈现的算是比拟晚的。本篇文章的余下技术内容，算是目前为止首次由手机厂商分享的自建零碎级推送平台的技术细节，咱们一起来学习。 5、从技术角度理解推送平台推送平台是做什么的？从技术的角度上来看，推送平台就是一个通过TCP长连贯，将音讯发送给用户的平台。所以推送平台的实质其实就是借助网络通道，将音讯发送到用户设施上。 大家日常都收到过快递告诉吧！当快递员将快递放到快递柜中，快递后盾就会主动推送一条音讯，告诉你有快递。我置信，如果你是一位经营人员，你也会喜爱这种主动下发音讯高效的形式。大家感兴趣的，能够通过vivo开放平台入口，抉择音讯推送来更进一步理解更多技术细节，这里就不做开展了。 6、短连贯与长连贯音讯推送平台的实质，就是通过长连贯将内容、服务、用户连在一起，将内容分发给用户，为终端设备提供实时、双向通信能力。这里有个概念长连贯，那么什么是长连贯？所谓的长连贯就是：客户端与服务端维持的一条、在绝对较长的工夫里、都可能进行网络通信的网络连接（比方：基于TCP的长连贯）。 为什么咱们要采纳长连贯而不是短连贯作为平台底层的网络通信？先来看看短连贯下音讯下发的场景：应用短连贯的形式就是轮询，即客户端定时的去询问后盾有没有设施A的音讯，当有设施A的音讯时后盾返回对应的音讯，可能很多状况下都是无功而返，节约流量。当后盾有音讯须要发送给设施A时，因为设施A没有过去取导致音讯无奈下发。 而应用长连贯：当有设施A的音讯时后盾间接发送给设施A而不必等设施A本人过拉取，所以长连贯让数据交互更加天然、高效。 7、业务需要驱动架构降级对于零碎的技术架构来说，它是动静的，不同阶段都可能会发生变化。而推动架构进行演进的推力，次要来自于业务需要，一起来回顾，平台的业务倒退历程。 自2015年立项以来，随着业务量增长，一直为零碎增加性能个性，丰盛整个零碎的能力使其满足不同的业务场景需要。比方反对内容齐全审核、反对IM、反对IoT、反对WebSocket 通信等。从图上能够看到，业务量简直每年都有几十亿的增长，一直攀高，给零碎带来了挑战，原有的零碎架构存在的问题，也逐步浮出水面，比方提早、性能瓶颈。架构服务于业务，2018年之前咱们平台所有服务都放在云上，然而依赖的其余外部业务部署在自建机房。 随着业务量增长与自建机房的数据传输，曾经呈现了提早的问题，并且在逐步好转，不利于咱们平台性能的拓展。所以在2018年下半年，咱们对部署架构进行调整：将所有外围逻辑模块都迁徙到自建机房，架构优化之后，数据提早问题失去彻底解决，同时也为架构进一步演进奠定了根底。从下面的图中能够看到咱们接入网关也进行优化三地部署。 为什么要进行三地部署而不是更多区域部署呢？次要基于以下三点思考：1）第一是基于用户散布及老本的思考；2）第二是能为用户提供就近接入；3）第三是可能让接入网关具备肯定容灾能力。 大家能够构想下，如果没有三地部署，接入网关机房故障时，那么平台就瘫痪了。随着平台业务规模的进一步扩充，日吞吐量达到10亿的量级，用户对于时效性、并发要求越来越高。而2018年的逻辑服务的零碎架构曾经无奈业务高并发的需要或者须要更高的服务器老本能力满足高并发需要。所以从平台性能、老本优化登程，在2019年对系统进行了重构，为用户提供更加丰盛的产品性能及更稳固、更高性能的平台。 8、利用长连贯能力给更多业务赋能 作为公司较大规模的长连贯服务平台，团队积攒了十分丰盛的长连贯教训。咱们也始终在思考，如何让长连贯能力为更多业务赋能。咱们平台服务端各个模块之间通过RPC调用，这是一种十分高效的开发模式，不必每个开发人员都去关怀底层网络层数据包的。 咱们构想一下，如果客户端也能通过RPC调用后盾，这肯定是十分棒的开发体验。将来咱们将会提供VRPC通信框架，用于解决客户端与后盾通信及开发效率问题，为客户端与后盾提供统一的开发体验，让更多的开发人员不再关怀网络通信问题，分心开发业务逻辑。作为一个吞吐量超过百亿的推送平台其稳定性、高性能、平安都十分重要，接下来和大家分享，咱们在零碎稳定性、高性能、平安方面的实践经验。 9、vivo推送平台的畛域模型从上图的畛域模型能够看出，推送平台以通信服务作为外围能力，在外围能力的根底上咱们又提供了，大数据服务以及经营零碎，通过不同接口对外提供不同的性能、服务。以通信服务为外围的推送平台，其稳定性和性能都会影响音讯的时效性。 音讯的时效性是指，音讯从业务方发动用设施收到的耗时。那么如何掂量音讯的时效性呢？咱们持续往下看。 10、如何实现音讯时效性的监控与品质度量？ 传统的音讯时效性测量方法如上图左所示：发送端和接收端在两个设施上，在发送的时候取工夫t1、在接管到音讯的时候取工夫t2，这两个工夫相减失去音讯的耗时。然而这种办法并不谨严，为什么呢？因为这两个设施的工夫基准，很有可能是不统一的。 咱们采纳的解决方案如上图右图所示：将发送端和接收端放在同一个设施上，这样就能够解决工夫基准的问题。咱们就是基于该计划，搭建了一套拨测系统，来被动监控音讯送达耗时散布。 11、如何实现高性能、稳固的长连贯网关？过来10年探讨单机长连贯性能时面对的是单机一万连贯的问题（C10K问题），而作为一个上亿级设施同时在线的平台，咱们要面对的是单机100万连贯的问题。 作为长连贯网关，主要职责是保护与设施端的TCP连贯及数据包转发。对于长连贯网关：咱们应该尽可能使其轻量化。 咱们从以下几方面进行了自上而下的重构优化：1）架构设计；2）编码；3）操作系统配置；4）硬件个性配置。 具体的施行办法，比方：1）调整零碎最大文件句柄数、单个过程最大的文件句柄数；2）调整零碎网卡软中断负载平衡或者开启网卡多队列、RPS/RFS；3）调整TCP相干参数比方keepalive(须要依据宿主机的session工夫进行调整）、敞开timewait recycles；4）硬件上应用AES-NI指令减速数据的加解密。 通过咱们优化之后，线上8C32GB 的服务器能够稳固反对170万的长连贯。 另外一大难点在于连贯保活：一条端到端的 TCP连贯，两头通过层层路由器、网关，而每个硬件的资源都是无限的，不可能将所有TCP连贯状态都长期保留。所以为了防止TCP资源，被两头路由器回收导致连贯断开，咱们须要定时发送心跳申请，来放弃连贯的沉闷状态（为什么TCP有这样的问题？有趣味能够读这两篇：《为什么说基于TCP的挪动端IM依然须要心跳保活？》、《彻底搞懂TCP协定层的KeepAlive保活机制》）。 心跳的发送频率多高才适合？发送太快了会引起功耗、流量问题，太慢了又起不到成果，所以为了缩小不必要的心跳及晋升连贯稳定性，咱们采纳智能心跳，为不同网络环境采纳差异性的频率。 无关长连贯心跳机制的更详细资料，能够参阅：《手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制》《一文读懂即时通讯利用中的网络心跳包机制：作用、原理、实现思路等》《挪动端IM实际：实现Android版微信的智能心跳机制》《挪动端IM实际：WhatsApp、Line、微信的心跳策略剖析》《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》《正确理解IM长连贯、心跳及重连机制，并入手实现》《万字长文：手把手教你实现一套高效的IM长连贯自适应心跳保活机制》《Web端即时通讯实际干货：如何让你的WebSocket断网重连更疾速？》 12、如何实现亿级设施的负载平衡？咱们平台超过亿级设施同时在线，各个设施连贯长连贯网关时是通过流量调度零碎进行负载平衡的。当客户端申请获取IP时，流量调度零碎会下发多个就近接入网关IP： 那么调度零碎是如何确保下发的ip是可用的呢？大家能够简略思考下。 对于我来来说，咱们采纳四种策略：1）就近接入 ；2）公网探测 ；3）机器负载；4）接口成功率。 到底采纳这几种策略呢？大家能够想下，这两个问题： 1）内网失常，公网就肯定能联通吗？2）连接数少服务器，就肯定是可用的吗？ 答案是否定的，因为长连贯网关与流量调度零碎是通过内网进行心跳保活的，所以在流量调度零碎上看到的长连贯网关是失常的，然而很有可能长连贯网关公网连贯是异样的比方没有开明公网权限等。 所以咱们须要联合多种策略，来评估节点的可用性，保障系统的负载平衡、为零碎稳定性提供保障。 13、如何满足高并发需要？有这么一个场景：以每秒1000的推送速度，将一条新闻发送给几亿用户，那么有的用户可能是几天后才收到这条音讯，这就十分影响用户体验，所以高并发对音讯的时效性来说是十分重要的。 从上图的推送流程来看：会不会感觉TiDB会成为推送的性能瓶颈？其实不会：初步看可能会感觉它们作为核心存储，但因为咱们采纳分布式缓存，将核心存储的数据，依据肯定的策略缓存到各个业务节点，充分利用服务器资源，晋升零碎性能、吞吐量。咱们线上的分布式缓存命中率99.9% 为核心存储挡住了绝大部分申请，即便TiDB短时间故障，对咱们影响也比拟小。 14、如何保障系统稳定性？14.1 概述作为推送平台，平台的流量次要分为内部调用及外部上下游之间的调用。它们大幅稳定都会影响零碎的稳定性，所以须要进行限流、控速，保障系统稳固运行。 14.2 推送网关限流 推送网关作为流量入口，其稳定性十分重要。要让推送网关稳固运行，咱们首先要解决流量平衡的问题即防止流量歪斜的问题。因为流量歪斜之后，很有可能会引起雪崩的状况。咱们是采纳轮询的机制，进行流量的负载平衡，来防止流量歪斜问题。然而这里有两个前提条件：1）所有推送网关节点，服务器配置要保持一致，否则很有可能会因为某个解决能力有余导致过载问题；2）应管制流入咱们零碎的并发量，防止流量洪峰穿透推送网关导致后端服务过载。咱们采纳的是令牌桶算法，管制每个推送网关投放速度，进而可能对上游节点起到爱护作用。那么令牌数量设置多少才适合呢？设置低了，上游节点资源不能充分利用；设置太高了，上游节点有可能扛不住。 咱们能够采纳被动+被动的动静调整的策略：1）当流量超过上游集群解决能力时，告诉上游进行限速；2）当调用上游接口超时，达到肯定比例是进行限流。 14.3 零碎外部限速：标签推送平滑下发既然推送网关曾经限流了，为什么外部节点之间还要限速？ ...

11月来了 又到了商家打折、顾客剁手的节令图片 点击中转 > > mPaaS 折扣会场 < < 2021年阿里云双11大促【正式场】将于11月1日正式开启，此次双11 mPaaS 为挪动开发者们带来了哪些优惠活动呢？让咱们一一梳理 MPS：开发必备组件 6 折购一键集成华为、小米等多厂商推送通道忽视终端机型，精确触达用户 业余的挪动音讯推送计划，针对不同的场景推出多种推送类型，满足个性化推送需要。反对国内外支流厂商通道集成，最大可能晋升达到率。推送全流程外围指标可视化剖析监控。低成本集成，开箱即用。 mPaaS 平安服务 8 折购利用加固：源自于淘系利用上亿级业务安防锻炼针对挪动利用普遍存在的破解、篡改、盗版、内存调试等各类平安危险，提供深度的防逆向、防调试、防篡改爱护；同时，针对 JavaByteCode 级别提供当先行业的混同爱护，全面爱护代码逻辑。 操作简便、清晰，兼顾安全性与兼容性，极低解体率。破解者难以逆向剖析其原始代码逻辑，充沛保障应⽤安全性。 利用隐衷合规检测根据国家相干法律法规及行业标准，对挪动APP隐衷平安、集体数据收集和应用进行合规剖析。帮忙企业及APP开发者辨认平安危险，提供对应的专家整改倡议，助力客户躲避监管处罚及通过利用审核上架 。 隐衷协定检测，业余法务解读。敏感权限、个人信息采集行为辨认定位定制化场景检测 mPaaS 更多热卖资源包一键洽购 mPaaS 外围根底能力，让老本更可控。 本期上架的资源包套餐及其优惠详情如下： 月度资源包：按月洽购“实时公布+端上剖析”外围能力，享 8.5 折特惠。年度资源包：按年洽购外围能力，送 mPaaS 等全套根底能力。点击理解资源包更多详情

亲，爆款产品折上折，全场 5.9 元包邮！福利来袭，充值送好礼~道具特惠，动手不亏。【关注 融云寰球互联网通信云】毫无疑问，11 月还没到，“双 11”先到了。不仅是剁手 APP，各大利用都搜索枯肠趁着这股风来一波大促，或回馈用户，或加强粘性，或冲刺 KPI。而将这些好消息传播给用户，音讯推送（Push）是最间接的形式。 现在，大部分手机 APP 都有音讯推送性能。作为揭示或唤醒用户的形式之一，用好推送是高效达成经营指标的重要抓手。 进步产品活跃度、晋升用户粘性和留存率，须要精细化经营策略，更须要高送达率和用户分层服务能力等底层技术的撑持。在音讯推送服务上，思考到开发成本和送达率，大部分 APP 会优先思考借力融云等第三方服务商。 融云作为专一通信云赛道多年的 PaaS 厂商，以 IM+RTC+X“全”通信解决方案高效赋能开发者。其中，推送是融云最早打造的 X 能力之一。开发者只需集成一套融云的 IM SDK，无需再自行逐个对接多家手机品牌厂商，即可取得毫秒级触达指标用户的极致体验。联合标签推送、多种推送场景和推送统计等能力，让 APP 精准“击中”指标用户。 一站式推送，精细化经营俗话说，不合乎用户习惯的推送都是耍流氓。推送经营须要均衡用户体验和平台指标，最终让用户称心，为平台带来价值。融云推送服务不仅笼罩全平台，还凋谢 API 接口，供开发者依据用户画像实现多场景的精准推送，并提供统计等一站式服务。 推送平台全笼罩 全面笼罩小米、华为、OPPO、vivo、魅族、一加、Realme、FCM、APNs 手机零碎级推送通道，可保障推送成功率。 融云目前曾经跟各大厂商的推送平台做好对接，应用融云 SDK 能够一站式取得对接各厂商推送平台的能力，毋庸独自做对接。 **全量 & 标签推送** 依据用户属性设置用户标签、进行标签分组，建设精准用户画像，让推送更精准，晋升推送点击率、转化率及用户留存率。基于用户的个性化需要实现推送，既能够进步转化率，又满足用户所想。 多种推送场景反对 反对文本、富媒体、自定义音讯等内容推送，吸引用户点击，满足各场景的推送经营需要，如：社交互动告诉、交易状态同步告诉、系统升级、帐号唤醒拉活告诉、流动经营告诉等。 推送统计能力 推送成果剖析，通过融云平台反对查看各手机厂商平台推送数据状况，如推送的胜利、失败、达到、点击，无效把握推送品质状况。 音讯级推送属性设置 单聊、群聊场景下，发送单条音讯时可设置该条音讯的推送属性，如：推送题目、推送内容、推送 channel_Id、通道类型、是否强制显示推送告诉等，开发者可依据业务须要进行灵便设置。 推送多语言模板设置 在寰球业务中，利用的终端用户散布于多个国家，在发送系统升级、经营流动类告诉时，须要给不同语言环境的用户推送不同的经营内容。 通过推送模板，可依据指标用户设置的语言环境，从推送模板中抉择对应语言的内容进行近程推送，加强经营成果，晋升用户应用体验。 积攒深厚，劣势当先凭借融云在 IM 即时通讯畛域的深厚技术积攒，以及多年稳固牢靠的音讯推送服务能力，融云推送服务具备多方面当先劣势。 一套 SDK 解决所有问题 只需集成一套融云 IM SDK，即可取得 IM 即时通讯能力和推送经营能力，可简略疾速实现利用内的零碎告诉和站内揭示模块；不便业务经营，晋升留存率和召回率；节俭了开发者须要同时对接多个厂商的工夫和精力，升高开发和应用老本。 同时，融云搭建业余团队随时响应开发者征询，解答开发者疑难，帮助开发者定位、剖析问题。 底层架构弱小，高效散发 融云通信网络覆盖寰球 233 个国家及地区，领有几千个动静减速节点，可急速触达用户。 为保障高效，融云通过分组散发和批量解决两个模型进行推送散发，采纳统一哈希算法，一次推送申请只跟上游节点数无关，不受设施数量影响，极大晋升散发效率。 多通道策略，保障送达率 融云 SDK 对接了各厂商推送，配合搭建的自有推送通道，智能抉择最优计划，最大水平保障了推送达到率和时效性，给开发者毫秒级触达指标用户的极致体验。 ...

一、是什么进程间的一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息 二、命令subscribe c1 c2 c3 // 可以一次性订阅多个publish c2 hellow // 给c2发布xiaoxipsubscribe new* // 订阅多个，通配符*三、案例 在另一个会话窗口发送消息 一次订阅多个 发布消息

上一篇小程序发送模板消息的几种实现主要介绍了实现评论通知功能最重要的一环，这篇文章主要介绍实现该功能的具体实战。实现流程思路其实很简单，简单画了个流程图如下： 这里有两个比较坑的地方，一个是微信本身发送模板消息的限制： 当用户在小程序内发生过提交表单行为且该表单声明为要发模板消息的，开发者需要向用户提供服务时，可允许开发者向用户在7天内推送有限条数的模板消息（1次提交表单可下发1条，多次提交下发条数独立，相互不影响）另外一个就是管理员如何初始化自己的formId的问题，而且自身的formId需求量比较大，读者评论完之后就要向管理员推送消息。 所以无奈，增加了一个后台配置的功能，定期手动触发去生成自己的FormId「自动不行，只能手动，泪奔中」 另外补充下，网上说的通过嵌套穿透的方式无限获取formId的方式已经行不通了，生成出来的formId都是一样的。 评论提交收集FormId首先我们需要收集用户的FormId,有FormId才能发送对应的模板消息，在表单标签上加上report-submit属性即可。 <form catchsubmit="formSubmit" report-submit="true">这样我们在提交评论表单的时候会获取到对应的FormId, 我们将这个FormId保存至我们的云函数中。 //评论提交按钮部分代码console.info(e.detail.formId)if (e.detail != undefined && e.detail.formId != undefined) { var data = { formId: e.detail.formId, author: 0, timestamp: new Date().getTime() } wxApi.insertFormIds(data).then(res => { console.info(res) }) } //调用云数据库function insertFormIds(data) { return db.collection('openid_formids').add({ data: data })}这样管理员在接收到评论之后回复时就可以到openid_formids的集合中找到对应的formId来进行评论回复的模板消息推送了。 管理员生成FormId为了让管理员能有更多的FormId来接收评论通知，因此我在小程序中搭建了个生成FormId的小页面。 这样偶尔登录自己的小程序，查看下自己FormId的使用情况，若没有了可以手动生成几个。 当然，这里会有一个权限问题，理论上这个页面只有管理员才可以展示，而其他人是没有权限访问的，因此需要提供个验证权限的云函数。 这里可以使用云函数的环境变量来简单做个验证，将你的管理员的openId配置在环境变量中，云函数验证下openId是否一致即可。 云函数代码如下，这样代码中不会存放敏感信息，开源的代码上传github也不会泄露。 /** * 验证 * @param {} event */async function checkAuthor(event) { if (event.userInfo.openId == process.env.author) { return true; } return false;}发送模板消息最后就是发送模板消息的实现了，方法在上一篇说的比较具体了，基于我的博客小程序，使用云调用是最方便的。 ...

「模板消息」能力，几乎是小程序触达用户的唯一渠道。有了它，运营人员才有足够的发挥空间，来提高用户的留存，转化。微信为了防止有人用模板消息频繁骚扰用户，推出了一套严格的监督机制。一旦发现有人滥用，立刻对模板消息进行封禁处理，这将直接影响线上业务。然而受人为因素影响，模板消息的审查有很大的不确定性，运营者即使遵照微信运营规范执行也有可能被误伤封禁。以下是模版消息被封的一些常见原因。模版消息被封的常见原因：同一时间段大批量发送，被系统判定为行为异常。推送内容违规或推送内容与用户需求不符，导致用户举报。推送次数过于频繁，一天内向同一个用户推送多次模板消息，导致用户举报。简单总结，主要还是因为模板消息推给了不该推的人，被人当垃圾邮件一样处理，自然容易被封。「知晓推送」就针对以上场景做了功能优化，其新推出的智能推送服务可以助力小程序高效匹配目标用户，极大的降低模板消息被封的概率，为小程序业务的稳定运行再上一层保险。除此之外，「知晓推送」还解决了你的难题：运营灵活性差，每次推送内容变更都得通过修改代码来实现。formid 限制太大，收集麻烦，每一次业务变更都需要重新埋点。推送成本高，后端服务需要单独开发，还不能保证消息推送的稳定性与效率。「知晓推送」提前尝鲜5 月 8 日，我们将正式推出「知晓推送」服务，帮助运营者处理好粉丝转化、消息推送、数据分析等多个层面的麻烦事，真正解决复购难、留存差的问题。四大核心功能助力实现小程序用户的高效转化：1.在线发送完全可视化操作，提前预览发送效果。让模板消息推送变得和发微博一样简单。使用在线推送服务，运营人员不用在对着代码一脸懵逼了。2.自动收集 formid 组件让 formid 不足导致无法推送模板消息的状况成为过去式，两行代码即可完成接入，业务变更也无需重复埋点。3.智能推送支持根据自定义规则过滤出与小程序匹配的目标用户，同时可以设置同一批模板消息的推送次数与单次发送数量，避免骚扰用户，实现精准推送，高效转化。4.便宜限时福利大放送「知晓推送」正式上线前完全免费，服务上线当天还有额外福利。5.8 日前注册的用户都可获赠价值不少于 198 元的资源包（详询，微信：minsupport3）哦！抓紧时间注册吧～

作者：个推平台研发工程师 祥子一、业务背景在个推的推送场景中，消息队列在整个系统中占有非常重要的位置。当 APP 有推送需求的时候, 会向个推发送一条推送命令，接到推送需求后，我们会把APP要求推送消息的用户放入下发队列中，进行消息下发；当同时有多个APP进行消息下发时，难免会出现资源竞争的情况, 因此就产生了优先级队列的需求，在下发资源固定的情况下, 高优先级的用户需要有更多的下发资源。二、基于 Kafka 的优先级队列方案针对以上场景，个推基于 Kafka 设计了第一版的优先级队列方案。Kafka 是 LinkedIn 开发的一个高性能、分布式消息系统；Kafka 在个推有非常广泛的应用，如日志收集、在线和离线消息分发等。架构在该方案中，个推将优先级统一设定为高、中、低三个级别。具体操作方案如下：对某个优先级根据 task (单次推送任务)维度，存入不同的 Topic，一个 task 只写入一个 Topic，一个 Topic 可存多个 task；消费模块根据优先级配额(如 6:3:1)，获取不同优先级的消息数，同一优先级轮询获取消息；这样既保证了高优先级用户可以更快地发送消息，又避免了低优先级用户出现没有下发的情况。Kafka 方案遇到的问题随着个推业务的不断发展，接入的 APP 数量逐渐增多，第一版的优先级方案也逐渐暴露出一些问题：当相同优先级的 APP 在同一时刻推送任务越来越多时，后面进入的 task 消息会因为前面 task 消息还存在队列情况而出现延迟。如下图所示, 当 task1 消息量过大时，在task1 消费结束前，taskN 将一直处于等待状态。Kafka 在 Topic 数量由 64 增长到 256 时，吞吐量下降严重，Kafka 的每个 Topic、每个分区都会对应一个物理文件。当 Topic 数量增加时，消息分散的落盘策略会导致磁盘 IO 竞争激烈，因此我们不能仅通过增加 Topic 数量来缓解第一点中的问题。基于上述问题，个推进行了新一轮的技术选型, 我们需要可以创建大量的 Topic, 同时吞吐性能不能比 Kafka 逊色。经过一段时间的调研，Apache Pulsar 引起了我们的关注。三、为什么是 PulsarApache Pulsar 是一个企业级的分布式消息系统，最初由 Yahoo 开发，在 2016 年开源，并于2018年9月毕业成为 Apache 基金会的顶级项目。Pulsar 已经在 Yahoo 的生产环境使用了三年多，主要服务于Mail、Finance、Sports、 Flickr、 the Gemini Ads platform、 Sherpa (Yahoo 的 KV 存储)。架构Topic 数量Pulsar 可以支持百万级别 Topic 数量的扩展，同时还能一直保持良好的性能。Topic 的伸缩性取决于它的内部组织和存储方式。Pulsar 的数据保存在 bookie (BookKeeper 服务器)上，处于写状态的不同 Topic 的消息，在内存中排序，最终聚合保存到大文件中，在 Bookie 中需要更少的文件句柄。另一方面 Bookie 的 IO 更少依赖于文件系统的 Pagecache，Pulsar 也因此能够支持大量的主题。消费模型Pulsar 支持三种消费模型：Exclusive、Shared 和Failover。Exclusive (独享)：一个 Topic 只能被一个消费者消费。Pulsar 默认使用这种模式。Shared(共享)：共享模式，多个消费者可以连接到同一个 Topic，消息依次分发给消费者。当一个消费者宕机或者主动断开连接时，那么分发给这个消费者的未确认(ack)的消息会得到重新调度，分发给其他消费者。Failover (灾备)：一个订阅同时只有一个消费者，可以有多个备份消费者。一旦主消费者故障，则备份消费者接管。不会出现同时有两个活跃的消费者。Exclusive和Failover订阅，仅允许一个消费者来使用和消费每个订阅的Topic。这两种模式都按 Topic 分区顺序使用消息。它们最适用于需要严格消息顺序的流(Stream)用例。Shared 允许每个主题分区有多个消费者。同一个订阅中的每个消费者仅接收Topic分区的一部分消息。Shared最适用于不需要保证消息顺序队列(Queue)的使用模式，并且可以按照需要任意扩展消费者的数量。存储Pulsar 引入了 Apache BookKeeper 作为存储层，BookKeeper 是一个专门为实时系统优化过的分布式存储系统，具有可扩展、高可用、低延迟等特性。具体介绍，请参考 BookKeeper官网。SegmentBookKeeper以 Segment (在 BookKeeper 内部被称作 ledger) 作为存储的基本单元。从 Segment 到消息粒度，都会均匀分散到 BookKeeper 的集群中。这种机制保证了数据和服务均匀分散在 BookKeeper 集群中。Pulsar 和 Kafka 都是基于 partition 的逻辑概念来做 Topic 存储的。最根本的不同是，Kafka 的物理存储是以 partition 为单位的，每个 partition 必须作为一个整体(一个目录)存储在某个 broker 上。 而 Pulsar 的 partition 是以 segment 作为物理存储的单位，每个 partition 会再被打散并均匀分散到多个 bookie 节点中。这样的直接影响是，Kafka 的 partition 的大小，受制于单台 broker 的存储；而 Pulsar 的 partition 则可以利用整个集群的存储容量。扩容当 partition 的容量达到上限后，需要扩容的时候，如果现有的单台机器不能满足，Kafka 可能需要添加新的存储节点，并将 partition 的数据在节点之间搬移达到 rebalance 的状态。而 Pulsar 只需添加新的 Bookie 存储节点即可。新加入的节点由于剩余空间大，会被优先使用，接收更多的新数据；整个扩容过程不涉及任何已有数据的拷贝和搬移。Broker 故障Pulsar 在单个节点失败时也会体现同样的优势。如果 Pulsar 的某个服务节点 broker 失效，由于 broker 是无状态的，其他的 broker 可以很快接管 Topic，不会涉及 Topic 数据的拷贝；如果存储节点 Bookie 失效，在集群后台中，其他的 Bookie 会从多个 Bookie 节点中并发读取数据，并对失效节点的数据自动进行恢复，对前端服务不会造成影响。Bookie 故障Apache BookKeeper 中的副本修复是 Segment (甚至是 Entry)级别的多对多快速修复。这种方式只会复制必须的数据，这比重新复制整个主题分区要精细。如下图所示，当错误发生时， Apache BookKeeper 可以从 bookie 3 和 bookie 4 中读取 Segment 4 中的消息，并在 bookie 1 处修复 Segment 4。所有的副本修复都在后台进行，对 Broker 和应用透明。当某个 Bookie 节点出错时，BookKeeper会自动添加可用的新 Bookie 来替换失败的 Bookie，出错的 Bookie 中的数据在后台恢复，所有 Broker 的写入不会被打断，而且不会牺牲主题分区的可用性。四、基于 Pulsar 的优先级队列方案在设计思路上，Pulsar 方案和 Kafka 方案并没有多大区别。但在新方案中，个推技术团队借助 Pulsar 的特性，解决了 Kafka 方案中存在的问题。根据 task 动态生成 Topic，保证了后进入的 task 不会因为其他 task 消息堆积而造成等待情况。中高优先级 task 都独享一个 Topic，低优先级 task 共享 n 个 Topic。相同优先级内，各个 task 轮询读取消息，配额满后流转至下一个优先级。相同优先级内, 各个 task 可动态调整 quota， 在相同机会内，可读取更多消息。利用 Shared 模式, 可以动态添加删除 consumer，且不会触发 Rebalance 情况。利用 BookKeeper 特性，可以更灵活的添加存储资源。五、Pulsar 其他实践不同 subscription 之间相对独立，如果想要重复消费某个 Topic 的消息，需要使用不同的 subscriptionName 订阅；但是一直增加新的 subscriptionName，backlog 会不断累积。如果 Topic 无人订阅，发给它的消息默认会被删除。因此如果 producer 先发送，consumer 后接收，一定要确保 producer 发送之前，Topic 有 subscription 存在(哪怕 subscribe 之后 close 掉)，否则这段时间发送的消息会导致无人处理。如果既没有人发送消息，又没有人订阅消息，一段时间后 Topic 会自动删除。Pulsar 的 TTL 等设置，是针对整个 namespace 起效的，无法针对单个 Topic。Pulsar 的键都建立在 zookeeper 的根目录上，在初始化时建议增加总节点名。目前 Pulsar 的 java api 设计，消息默认需要显式确认，这一点跟 Kafka 不一样。Pulsar dashboard 上的 storage size 和 prometheus 上的 storage size (包含副本大小)概念不一样。把dbStorage_rocksDB_blockCacheSize 设置的足够大；当消息体量大，出现backlog 大量堆积时, 使用默认大小(256M)会出现读耗时过大情况，导致消费变慢。使用多 partition，提高吞吐。在系统出现异常时，主动抓取 stats 和 stats-internal，里面有很多有用数据。如果业务中会出现单 Topic 体量过大的情况，建议把 backlogQuotaDefaultLimitGB 设置的足够大(默认10G), 避免因为默认使用producer_request_hold 模式出现 block producer 的情况；当然可以根据实际业务选择合适的 backlogQuotaDefaultRetentionPolicy。根据实际业务场景主动选择 backlog quota。prometheus 内如果发现读耗时为空情况，可能是因为直接读取了缓存数据；Pulsar 在读取消息时会先读取 write cache, 然后读取 read cache；如果都没有命中, 则会在 RocksDB 中读取条目位子后，再从日志文件中读取该条目。写入消息时, Pulsar 会同步写入 journal 和 write cache；write cache 再异步写入日志文件和 RocksDB； 所以有资源的话，建议 journal 盘使用SSD。六、总结现在, 个推针对优先级中间件的改造方案已经在部分现网业务中试运行，对于 Pulsar 的稳定性，我们还在持续关注中。作为一个2016 年才开源的项目，Pulsar 拥有非常多吸引人的特性，也弥补了其他竞品的短板，例如跨地域复制、多租户、扩展性、读写隔离等。尽管在业内使用尚不广泛, 但从现有的特性来说, Pulsar 表现出了取代 Kafka 的趋势。在使用 Pulsar 过程中，我们也遇到了一些问题, 在此特别感谢翟佳和郭斯杰(两位均为 Stream Native 的核心工程师、开源项目 Apache Pulsar 的 PMC 成员)给我们提供的支持和帮助。参考文献：[1] 比拼 Kafka, 大数据分析新秀Pulsar 到底好在哪(https://www.infoq.cn/article/...[2] 开源实时数据处理系统Pulsar：一套搞定Kafka+Flink+DB(https://juejin.im/post/5af414… ...