按照现时的最佳实践，那就是对接种手机厂商的ROOM级推送通道。具体我就不在这里展开，有兴趣的地可以详读《Android P正式版即将到来：后台应用保活、消息推送的真正噩梦》。...4、业务过滤机制设计 各个业务方可以无脑给用户发推送，但推送系统要有节制，因此要对业务消息有选择的过滤。...因为每天会进行一两次全局推，且针对沉默用户（即不常使用APP的用户）也有专门的推送，存储方面实际上不存在“热点”，虽然使用了缓存，但作用很有限，且占用空间巨大。...多分表以及缓存导致数据存在三四个副本，不同逻辑使用不同副本，经常出现不一致问题（追求一致则影响性能）， 查询代码非常复杂且性能较低。...2）先拉取高优先级topic的数据：只要有就一直消费，直到没有数据再消费低一级topic。消费低一级topic的过程中，如果发现有高一级topic消息到来，则转向消费高优先级消息。
按照现时的最佳实践，那就是对接种手机厂商的ROOM级推送通道。具体我就不在这里展开，有兴趣的地可以详读《Android P正式版即将到来：后台应用保活、消息推送的真正噩梦》。...4、业务过滤机制设计 各个业务方可以无脑给用户发推送，但推送系统要有节制，因此要对业务消息有选择的过滤。...5.png 因为每天会进行一两次全局推，且针对沉默用户（即不常使用APP的用户）也有专门的推送，存储方面实际上不存在“热点”，虽然使用了缓存，但作用很有限，且占用空间巨大。...多分表以及缓存导致数据存在三四个副本，不同逻辑使用不同副本，经常出现不一致问题（追求一致则影响性能）， 查询代码非常复杂且性能较低。...2）先拉取高优先级topic的数据：只要有就一直消费，直到没有数据再消费低一级topic。消费低一级topic的过程中，如果发现有高一级topic消息到来，则转向消费高优先级消息。
常见的异常处理措施有： 多通道同步：采取多种方式进行数据同步，可以应对同步通道出故障的情况。例如针对用户账号数据同步可有MySQL主从同步和消息队列同步两种方式。...方案设计关键点有： 一般情况采取两通道即可； 数据库同步通道和消息队列同步通道不能采用相同的网络连接，可以一个走公网，一个走内网。 数据是可以重复覆盖的。...用户补偿：例如《炉石传说》2017年回档故障，暴雪给予每个用户大约价值人民币200元的补偿（25卡包）。 接口级故障应对方案 接口级故障的典型表现：系统并没有宕机，网络没有中断，但业务出现问题。...三阶段提交算法虽然避免了二阶段提交算法的协调者单点故障导致系统阻塞的问题，但同样存在数据不一致问题。 分布式一致性算法：主要目的是为了保证同一份数据在多个节点上的一致性，以满足CAP中的CP要求。...Paxos Paxos是被理论上证明为正确的算法（另外一个被数学家理论上证明的定理是CAP理论），但Paxos存在着理论特别复杂难以理解、确实很多细节难以实现的明显问题。
在EasyNVR级联上级平台后，播放视频流一分钟后出现了黑屏现相，然而EasyNVR平台视频可以一直播放，说明流没有问题。查看日志EasyNVR平台级联消息也是正确的。...再来查看EasyNVR的通道配置，用户配置的是按需，查找推流时的代码，发现按需播放需要发送保活消息，在保活消息发送超过一分钟后，如果没有再次更新保活时间将结束推流。...接着查找国标级联的Invite消息，发现NVR在收到消息后，没有定时更新保活时间，所以出现了上级平台播放一分钟后断流黑屏的现象。...只需要在接收到Invite消息时，在定时器中更新保活时间就能解决问题： 但是定时器也不能忘了退出，否则即使按需直播结束了播放也会继续推流，所以还需要在定时器中监听退出信号，接收到Bye消息时，在通道发送定时器退出信号...，停止更新保活时间，保证推流断开。
image.png 在EasyNVR级联上级平台后，播放视频流一分钟后出现了黑屏现相，然而EasyNVR平台视频可以一直播放，说明流没有问题。查看日志EasyNVR平台级联消息也是正确的。...再来查看EasyNVR的通道配置，用户配置的是按需，查找推流时的代码，发现按需播放需要发送保活消息，在保活消息发送超过一分钟后，如果没有再次更新保活时间将结束推流。...image.png 接着查找国标级联的Invite消息，发现NVR在收到消息后，没有定时更新保活时间，所以出现了上级平台播放一分钟后断流黑屏的现象。...只需要在接收到Invite消息时，在定时器中更新保活时间就能解决问题： image.png 但是定时器也不能忘了退出，否则即使按需直播结束了播放也会继续推流，所以还需要在定时器中监听退出信号，接收到Bye...消息时，在通道发送定时器退出信号，停止更新保活时间，保证推流断开。
这就引入了一个看似矛盾的地方：数据不一致业务肯定不会正常，但跨城异地肯定会导致数据不一致。 如果是强一致性要求的数据，例如银行存款余额、支付宝余额等，这类数据实际上是无法做到跨城异地多活的。...，不保证实时一致性 采用多种手段同步数据 消息队列方式:对于账号数据，由于账号只会创建，不会修改和删除（假设我们不提供删除功能），我们可以将账号数据通过消息队列同步到其他业务中心。...方案关键点： 一般情况下，采取两通道即可，采取更多通道理论上能够降低风险，但付出的成本也会增加很多。...数据库同步通道和消息队列同步通道不能采用相同的网络连接，否则一旦网络故障，两个通道都同时故障；可以一个走公网连接，一个走内网连接。...日志记录 主要用于用户故障恢复后对数据进行恢复，其主要方式是每个关键操作前后都记录相关一条日志，然后将日志保存在一个独立的地方，当故障恢复后，拿出日志跟数据进行对比，对数据进行修复。
ID丢失，会存到本地的文件中；3）client需要在本地维护一个等待ack队列，并配合timer超时机制，来记录哪些消息没有收到ack：N，以定时重发；4）客户端本地生成一个递增序列号发送给服务器，用作保证发送顺序性...针对上述第4）点：1）如果路由状态和channel通道不一致，比如有路由状态，没有channel通道（已关闭）那么，就会走离线消息流出，并且清除路由信息；2）动态重启gate，会及时清理路由信息。...消息给客户端B；5）客户端B收到消息后返回确认ack；6）server收到ack后更新消息的状态或者删除消息。...11.4消息顺序性如何保证（不乱序）消息乱序影响的因素：1）时钟不一致，分布式环境下每个机器的时间可能是不一致的；2）多发送方和多接收方，这种情况下，无法保先发的消息被先收到；3）网络传输和多线程，网络传输不稳定的话可能导致包在数据传输过程中有的慢有的快...图片17、高可用设计17.1心跳设计主要是：1）服务端检测到某个客户端迟迟没有心跳过来可以主动关闭通道，让它下线，并且清除在线信息和路由信息；2）客户端检测到某个服务端迟迟没有响应心跳也能重连获取一个新的连接
虽然Pike 1.0在Shark通道的基础上，进一步在协议层强化了心跳探测机制以提高通道可用性，但通道不能及时检测异常还是时有发生。...Pike特性如下： 断线重连：鉴于长连接的不稳定特征，Pike 2.0通道通过断线重连机制来使的业务方可以认为在网络没有发生故障的情况下是持续可用的。...Pike 2.0首先会在触发通道异常检测的时候获取当前通道状态，如果通道当前没有主动关闭但是通道处于不可用的状态，Pike 2.0会强制执行一次自启动；此外，在通道巡检的过程中，巡检管理器会不断收集消息收发过程中出现的超时异常...如图所示，客户端可以在发送窗口允许的范围内一次性将多条消息发送出去，服务端把收到的消息都按顺序缓存在消息队列中，然后串行的通过RPC调用将这些缓存的消息依序投递给业务服务器。...如图所示，流程中明确标注了客户端建立连接、发起鉴权、绑定别名等信令，点击对应信令可以跳转信令详情进一步查看该信令所携带的信息，再结合SDK埋点在美团日志服务Logan的离线日志就可以快速发现并定位问题。
但Android P官方公开的开发者资料来看，此版加入或强化的多项设备电量管理新特性，使得需要后台消息推送、应用保活的APP变的越来越困难，黑科技恐将成为历史。...，基本上如果你的应用没有被加入白名单，一旦处于后台就会被系统限制甚至干掉，但使用APP的用户才不听你这些解释——反正“我”就要你的APP能如期正常运行，开发者也是不得已而为之。...但是（这个但是真的很讨厌），不要高兴的太早，理想情况下对接厂商通道确实很爽，但现实很骨感。...对接厂商通道带来的麻烦，远比你想像的要多： 1）你得一家一家下载SDK、注册开发者账号、搞手机端对接、搞服务端对接； 2）各厂商的SDK都打包在一个APP里，可能存在各种兼容性问题； 3）因为ROOM...水准、服务稳定性参差不齐，对接起来难受吧； 6）有些手机小厂并没有自已的推送通道，你自建的推送能道还不能扔。
虽然Pike 1.0在Shark通道的基础上进一步在协议层强化了心跳探测机制以提高通道可用性，但通道不能及时检测异常还是时有发生。...； 7）独立通道：Pike 2.0默认所有业务是使用一条共享的通道，针对业务量大或者对吞吐量有要求的业务可以自动切换独享的通道来保证消息的投递成功率和时延； 8）通道保活：Pike 2.0在连接保活的基础上增加了通道巡检...Pike 2.0首先会在触发通道异常检测的时候获取当前通道状态，如果通道当前没有主动关闭但是通道处于不可用的状态，Pike 2.0会强制执行一次自启动。...如下图所示：客户端可以在发送窗口允许的范围内一次性将多条消息发送出去，服务端把收到的消息都按顺序缓存在消息队列中，然后串行的通过RPC调用将这些缓存的消息依序投递给业务服务器。...如下图所示：流程中明确标注了客户端建立连接、发起鉴权、绑定别名等信令，点击对应信令可以跳转信令详情进一步查看该信令所携带的信息，再结合SDK埋点在美团日志服务Logan的离线日志就可以快速发现并定位问题
Node2 同步 v1 成功 此时才能向 client 返回应答 如果此时 client 再去访问 Node2，不会出现不一致的情况 保 CP 失 A 当发生了网络分区，Node1 与 Node2...强一致性：系统写入什么，读出来的也会是什么，但实现起来往往对性能影响较大，例如之前 CP 的例子 例如：火车站售票，有就是有，没有就是没有，不能出现不一致的情况 典型算法：Paxos、Raft、ZAB...答案是 （写）多数派，集群节点设置为奇数，同步超过集群中 N/2 个节点成功，则向客户端返回 ok，但存在顺序性问题，如 3 描述 多数派写操作成功后的读一致性暂不考虑，思考下图中的两项操作，都满足了多数派通过...，但 S3 这台服务器并没有与 S1，S2 达成一致，要达到多数派内部一致性 image-20210902151020777 Paxos Paxos 是一种共识算法，目的是解决之前提到的写多数派时的顺序性问题...一旦此 Server 崩溃，选举新 Leader 执行操作，以日志复制为例（Log replication） ① 由 Leader 执行自己的日志记录 ② 将日志复制到其它 Server，会覆盖掉不一致的部分
通道绑定对应消息队列和发布消息 参数1：queue表示队列的名称 生产者代码： // 通道绑定对应消息队列 // 参数1：队列名称，如果队列不存在会自动创建 // 参数2：用来定义队列特性是否要持久化...结论： 如果消息队列不设置持久化，重启MQ服务后，没设置持久化的消息队列将会丢失 如果消息队列设置了持久化，但没有设置消息持久化，重启MQ服务后，队列不会丢失，但消息会丢失 消息持久化 从上面我们可以看到...，消息队列设置了持久化，但没有设置消息持久化，重启MQ服务后，队列不会丢失，但消息会丢失，怎么解决这个问题呢？...生产者与消费者通道绑定的参数一致性 生产者： // 通道绑定对应消息队列 // 参数1：队列名称，如果队列不存在会自动创建 // 参数2：用来定义队列特性是否要持久化 // 参数3：是否独占队列，表示只有当前连接可用该队列...// 通道绑定对应消息队列 // 参数1：队列名称，如果队列不存在会自动创建 // 参数2：用来定义队列特性是否要持久化 // 参数3：是否独占队列，表示只有当前连接可用该队列 // 参数4：是否在消费完成后自动删除队列
了解我们产品的用户知道，作为音视频流媒体行业的视频能力平台设计者，我们的产品不限设备品牌只要协议支持就可以接入做流转换，其中EasyNVR主要作为RTSP协议设备/平台接入，EasyGBS主要作为GB28181...image.png EasyNVR也可以级联其他支持GB28181协议的平台，有时级联到上级平台后，开启按需通道多屏播放，如果发送级联停止消息使播放器停止播放一路视频时，其它视频也会同时被停止播放。...image.png 我们排查了一下视频流，流在EasyNVR平台播放时正常，没有出现中断现象，说明流正常，那就有可能是保活机制的问题，在级联保活的地方打断点调试发现当上级平台发送停止消息关闭了定时器后其它通道的保活也都停止了...，查找代码发现保活的定时器是全局共用一个的，定时器关闭后所有的保活都会受到影响。...所以需要在Invite消息里单独为每个通道设置定时器并放在一个切片中： image.png 在收到停止消息时关闭定时器并删除切片里对应的定时器： image.png 在EasyNVR里停用国标级联时要关闭所有定时器并清空
了解我们产品的用户知道，作为音视频流媒体行业的视频能力平台设计者，我们的产品不限设备品牌只要协议支持就可以接入做流转换，其中EasyNVR主要作为RTSP协议设备/平台接入，EasyGBS主要作为GB28181...EasyNVR也可以级联其他支持GB28181协议的平台，有时级联到上级平台后，开启按需通道多屏播放，如果发送级联停止消息使播放器停止播放一路视频时，其它视频也会同时被停止播放。...我们排查了一下视频流，流在EasyNVR平台播放时正常，没有出现中断现象，说明流正常，那就有可能是保活机制的问题，在级联保活的地方打断点调试发现当上级平台发送停止消息关闭了定时器后其它通道的保活也都停止了...，查找代码发现保活的定时器是全局共用一个的，定时器关闭后所有的保活都会受到影响。...所以需要在Invite消息里单独为每个通道设置定时器并放在一个切片中： 在收到停止消息时关闭定时器并删除切片里对应的定时器： 在EasyNVR里停用国标级联时要关闭所有定时器并清空inviteArr
【一个明星发一条微博，执行一个insert，然后n多个select】 缓存穿透 缓存没有发挥作用，业务系统向缓存中读取，但并没有数据。...主备倒换和主从倒换在原有基础上增加角色倒换的功能。 互连式：主备机间建立状态传递的通道。 通道可以是网络连接，也可以是串口连接。 中介式 主备机不进行直接连接，而是通过中介传递信息。...主备 主机执行所有的计算任务 当主机损坏且无法恢复时，需要人工将备机升至主机，并且增加新的备机 冷备：程序包和配置文件准备好，启动服务器，但业务不启动；温备：业务已启动，但不对外提供服务 适用内部管理系统...） 异常处理（多通道同步，同步和访问结合，日志记录，用户补偿） 接口级故障应对方案 相对与概率小的机房火灾，断电等故障，接口故障发生的情况更多。...接口级故障： 内部：程序问题，计算机性能到达极限，导致数据库慢查询 外部：黑客攻击，促销抢购导致用户访问量突增，第三方响应缓慢等 降级 降级是着眼与整个系统的高可用，丢车保帅的一种行为。
Web端到Native端有很多种方式，支付宝采用的Js Console，相比其他方案它具有不占用系统及浏览器进程，也不会产生一些虚拟弹窗的优点。Native到Web较简单，通过运行JS就可以实现。...每次闪退触发都会自动上传；周期性检查上传是指按照一定的周期比例定期上传一些指标；由于开发过程中开发日志较多，无法做到每次上报，因此会通过驱动指令的方式将有问题的开发日志上传再进行分析； 4）诊断分析：首先有一个公共的闪退分析大盘...每次触发的逻辑都会同步到渲染层。当页面有一些操作，比如一个点击事件会先经过Message Channel发给对应的逻辑，逻辑处理后进行数据绑定，再通过消息通道回到具体页面进行渲染以完成流程。...如果需要调用Native能力，需要逻辑层去调用消息通道，然后再通过JS Bridge调用Native层提供的底层能力。...1）预加载：由于小程序是以离线包的形式进行下发的，因此预加载方式和加载时间就是要优化的方向； 2）小程序保活：在使用小程序时，为了保证退出后再次打开的场景的使用体验，会为小程序保活； 3）渲染优化：目前渲染是通过
对于关系型数据库，如MySQL，一般是有主从数据库的，为了保稳定和不影响主库的查询性能，我们一般抽取从库数据。...对于文件数据抽取前需要先检测文件是否存在，源系统提供文件的时候需要提供对应的校验文件，校验文件里一般包含文件的记录数、字段格式等信息。...数据上报：JS执行完毕后，会将所有收集到的信息拼装到一个请求内，通过日志请求将数据发送到日志服务器，存储为JSON文件；一般情况下，在 JS 执行完成后就会立即向日志服务器发送消息队列中。...数据存储：存储在磁盘上的文件会部署数据采集组件比如Flume，将采集到的日志数据发送到HDFS进行存储或者转存到HBase进行存储。消息队列的数据则可以直接消费落地到HDFS或者HBase进行存储。...用户的每个操作都会产生一个操作日志，但并不是每生成一条日志就实时上报至服务器，而是在产生日志后，先暂存在客户端本地，再结合着相应的上报控制策略进行数据上报。
如上图所示，为了保障链路存活，一套成熟的 IM 系统一般会包含消息链路和推送链路两条长连接通道。...4、链路保活的必要性 基于 TCP 的 Socket 连接建立之后，如果不做任何处理，这个连接会长时间存在并且可用吗？答案是否定的。...Android后台保活方案的真实运行效果（截止2019年前）》 6、消息链路保活机制 消息链路作为收发消息的主要通道，需要最大程度保障链路的可用性。...iOS 手机有 APNS 来达到以上效果（详见《了解iOS消息推送一文就够：史上最全iOS Push技术详解》），但安卓的官方推送系统 FCM 在国内基本不可用。...1.3）根据文件锁互斥原理，监视 Java 进程存活状态：若被杀， Linux 层成功持有文件，则通过 exec() 命令，打开一个纯 Linux 的可执行文件，开启一个 Daemon 进程, 该进程因为从
但缺点也很明显，有 2 个问题： 缓存利用率低：不经常访问的数据，还一直留在缓存中 数据不一致：因为是「定时」刷新缓存，缓存和数据库存在不一致（取决于定时任务的执行频率） 所以，这种方案一般更适合业务「...可见，先删除缓存，后更新数据库，当发生「读+写」并发时，还是存在数据不一致的情况。...主从库延迟和延迟双删问题 到这里，还有 2 个问题，是我们没有重点分析过的。 第一个问题，还记得前面讲到的「先删除缓存，再更新数据库」方案，导致不一致的场景么？...解决方案是「延迟双删」，但这个延迟时间很难评估，所以推荐用「先更新数据库，再删除缓存」的方案 5、在「先更新数据库，再删除缓存」方案下，为了保证两步都成功执行，需配合「消息队列」或「订阅变更日志」的方案来做...，延迟删除缓存，同时也要控制主从库延迟，尽可能降低不一致发生的概率 后记 本以为这个老生常谈的话题，写起来很好写，没想到在写的过程中，还是挖到了很多之前没有深度思考过的细节。
为了使kafka的吞吐率能水平扩展，物理上把topic分成 一个或多个partition，每个partition对应一个文件夹，存储所有这个partition的消息和索引文件。...3) 按消息key保序策略: 生产者在发送消息的时候，需要指定消息的key, 这个key下的所有消息都会放入同一个分区中，并且都是有序的。...2) 实现单调读 如果多个副本提供读请求，一个客户端第一次请求到了一个副本，下次到另外一个副本，由于副本之间不是一致性的，就会存在两次读请求数据不一致的问题。...追随者副本不处理客户端请求，它唯一的任务就是从领导者副本异步拉取消息，并写入到自己的提交日志中，从而实现与领导者副本的同步。...开启 Unclean 领导者选举可能会造成数据丢失，但好处是，它使得分区 Leader 副本一直存在，不至于停止对外提供服务，因此提升了高可用性。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
