写得太好了，正是我需要的，拜谢楼主

最近一直在看消息推送系统的资料，感谢分享

什么时候上支持离线数据的版本

引用：一夕 发表于 2019-02-26 11:41
我明白你的意思。正如你所说的技离开现实场景去讨论，就有点本末倒置了。在物联网通讯场景中，数据的可达 ...

你这不是普通通知，是硬件指令了，这要求就高了，我上面说的场景没有办法匹配的了你的要求

引用：JackJiang 发表于 2019-02-26 11:07
不只是用redis，分布式系统中这样的内存缓存服务都存在你说的这种风险，但实际上推送系统，它推送的只是 ...

我明白你的意思。正如你所说的技离开现实场景去讨论，就有点本末倒置了。在物联网通讯场景中，数据的可达性，及时性，有效性，远不是传统的手机端推送通知可比的，与其叫推送通知，我更喜欢叫做【命令下发】。在我从事的农业物联网行业，比如说远程开泵，关泵。严重依赖于整个下行链路的畅通，如果关键时刻无法正常操作，会导致水泵空转 或无法浇水，给农户造成损失这在水利局层面是绝对不允许的。更何况在工业物联网上，稍有不慎命令下方的不及时，早成的事故可以是血的教训。

引用：一夕 发表于 2019-02-26 10:55
个人感觉整个设计已经相当弹性了，非常不错。但是关于failover，版主能不能详细介绍一下。比如说，就上述设 ...

不只是用redis，分布式系统中这样的内存缓存服务都存在你说的这种风险，但实际上推送系统，它推送的只是一个通知，通知其实没有必要做到电商订单那样百分百保证的，就像你的淘宝订单一样，淘宝发给你的通知，可能因为种种原因，你没有收到或看到，或这并不影响淘宝订单的存在。

所以，你要认清推送系统的产品性质。技术离开现实场景去讨论，就有点本末倒置了。

个人感觉整个设计已经相当弹性了，非常不错。但是关于failover，版主能不能详细介绍一下。比如说，就上述设计平台下行的命令我理解严重依赖redis的路由信息表，但是redis一旦over了，那平台整个下行的命令就会全部崩溃。确实redis有很多高可用的方案，但是也不能保障数据100%的恢复，我理解其实这块路由的原始信息是存在 push-server，这块链路检测 数据恢复，是怎样的呢？或者版主有什么更好的方案。

支持作者谢谢分享~

引用：crossoverJie 发表于 2018-11-28 20:50
我很好奇小编去那儿找的照片，这都能找到

你是作者本人，哈哈。感谢你的分享，如果你个人信息有误，记得告诉我
这张照片比较乡土，跟真人比应该是最保真的，所以就选它了 ^_^

我很好奇小编去那儿找的照片，这都能找到

从0开始哇

学习了,非常感谢!

不错啊，学习了