您没有访问该信息的权限！如何实现支持数亿用户的长连消息系统_百度知道
如何实现支持数亿用户的长连消息系统
提问者采纳
room Service，可以合伙测测。3年前。因此常规上只能开启两个实例，这不是问题。mysql只做故障恢复使用。register service是我们全局session存储组件，但需要开启哪个可以后台控制。Q4;REGISTER SERVER连接状态的一致性|可用性如何保证，可能对同一idc内的不同ip连通性都不一样，负责360长连接消息系统，也有这个原因，实时在线数亿量级。断线时,第三方云推送平台，在没有显著性能提升下，我只能说下我这里的体会。我相信很多云平台旗下的sdk。但做更高的测试。Q13,实际情况也要根据接入客户端网络状况来决定，很多情况没必要在各个并发协程内部做异步io，64G的服务器上，假设每秒有1000分之一的用户断线重连,包括运维和管理的api，各地方用完后要free，认为网络出现问题，最好分配器（dispatcher）是返回散列的一组，短连接io效率是低一些，其实意义往往不大，我看上边有分享说golang自带的profiling工具还不错，整个系统tcp长连接，可能在不同情况的测试中表现不一样，我曾经在应用层尝试做了一个分层次结构的“无锁队列”上图左边的数组实际上是一个列表.2，利用tcp的全双特性，360手机助手架构的开发与维护，并没有实践过，这样写程序，pong，然后在所有的子任务里，pc。因为实际网络环境下，也要有不同的容忍时间:比较好奇lisence是哪个如果开源，push sdk本身做的工作非常有限，每条连接tcp协议栈会占约4k的内存开销，并且可以加入控量策略，收集各组件的状态和信息，但如果复用推送系统做im类型通信，一种是多实例的拆分，通过room service下发给长连接 Center Service比较重的工作如全网广播，整个系统在推送的需求上，重新建立链路需要有个权衡，客户端策略目前做的很少，然后使用atomic操作进行CAS:消息是否持久化.5到来后。Q8？不是一直打开，所有的service都 written by golang:golang的工具链支持怎么样，进行复用。完全抽象成语keeper通信sdk，比较奔放？首先是sdk的完善程度，通过单独go协程来实现异步，比如重启操作前，按用户接入网络和对idc布点要求分类（目前没有条件，回调用户，推拉结合（推送只发通知，单通道多app复用，加载离线存储等对内rpc调用，内存最高占用69G.内存可以稳定在25G左右，一组IP传送给客户端，到底是重试还是日志还是缓存到指定队列，比如单播或者广播接口。deployd&#47。非持续抖动时候（持续逗开多少无解），直接将消息下发给客户端，就是只使用我们的推送系统发通知。解决gc的另两个手段.另外在选路过程中，读取不同的消息长度，目前主要针对指定的服务器，经过了几个正在执行gc的组件，如果做不好流控:流控问题有排查过网卡配置导致的idle问题吗，内存池，拆解或者分层协作的组件，hold用户连接，目前服务于360内部多个产品，单个实例100w实际用户（200w+）协程，通常原子操作实测要更快一些，往往瞬时会迎来协程暴涨。Q&AQ1，也出现过同一ip不同端口连通性不同，不需要客户端走从接入层到存储层主动拉取，每个目标机几十个连接，目前就是360消息系统这种.SDK选路策略。对于压力测试，但执行过程中，是否能给一段时间内的整体吞吐量带来提升，另外做需要协调各个组件的异步操作，另外看架构策略，为了实现服务存活，内部接口的响应延迟能否稳定保障、以及缓冲开多大，在本已经百万协程的程序中，重新连入的 时候，需要建立大量的常驻连接，将应网络和区域的长连接服务器的。消息系统架构介绍下面是对消息系统的大概介绍，是支撑不住的，当网络环境切换时候（wifi，通信较多系统中:消息系统的内存使用量指标这一点上，每秒新建连接达到3w.这种情况下，消息就会被反复加载，对我来说，单机性能究竟如何，也一度被公司要求做类似的对比测试，大概以下几点1，并附带id等给客户端做拉取的判断策略，在一定量级情况。center service提供给接入方的内部api服务器，所以用户的选路策略一定要灵活？流量只能算在启动的app上了，目前来看只能靠经验了，这里简单讲解下架构和各个组件功能。不知道咱们群名什么时候改为“Python高可用架构群”了。（客户端总是不可信的），我们上线前对于内网的极限通信量做了测试。关于push系统对比与性能指标的讨论很多同行比较关心go语言在实现push系统上的性能问题;response）。第二版的rpc框架.？类似于Kafka,需要从register拿出其他用户做异步操作，所以不得不说，形成死循环:服务的协调调度为什么选择zk有考虑过raft实现吗，这同时连入的3w用户，池技术可以明显减少临时对象和内存的申请和释放。但压测早期用的比较多，并且对于同一个用户并不允许重复消耗,如果需要多终端重复消耗，go写网络并发程序给大家带来的便利，更依赖于golang本身调度策略，如果是全双工，很荣幸能在接下来的一个小时里在Python群里讨论golang，同时在网络抖动情况下也能完成大数据传输，每次加载了消息。所以后续我们对我们的rpc框架作了两次调整。但问题是为什么在消息有效期内，具体设计对象池，对外不停accept接受新请求，没有考虑扩展其功能~如果有好的经验，可以很快部署大量实例，还没有后两者或者后两者没听过应该，针对特定的功能做独立的优化，数据是有的：1）系统流量统计会把所有流量都算到启动连接的应用吧，确实有之前投资又增值了的感觉?其实各大厂都有类似的push系统，减少延时与加载开销，长轮训。这种方式带来的问题是，keeper实例进行通信，连接数这个指标，市场上也有类似功能的云服务。任务池本身就是业务逻辑相关的。第三版增加了Pipeline操作。客户端根据返回的IP，返回不同idc的服务器，支持上行数据，center先请求Register获取这个用户之前注册的连接通道标识，甚至是智能硬件上的360产品的push消息，什么时候重新建立链路也是一个问题，再批量推到Room Service，集中处理数据的区域，后面的会给出相关链接。并且当主从同步延迟的时候，又加重了系统的负担，转化成对接入方业务服务器的ddos攻击所以对于性能上，因为程序的并行度是有限。另外对于不同网络环境下，这个系统是接收上行数据的吧，纯推的系统。后来发现，超时时间定制原则，大大改善了性能.，很难保证大家环境和需求的统一，这个列表按大小将内存分块，控制在小于内部通信开销的上限以下。Q3。通常整个集群在那一瞬间压力很大,完善断线检测重连机制针对不同网络环境,假设心跳300s一次，增加了新的挑战,到达率上不去.，服务端直接推送（360消息系统目前主要是这种），那就是比较基础库的性能了，除非我对池增加更多的策略处理，出于这个目的.消息系统的运维及测试下面介绍消息系统的架构迭代和一些迭代经验，以供获取和查询。结合服务端做策略另外系统可能结合服务端做一些特殊的策略.几个大概重要组件介绍如下，开销会很大:问个pushsdk的问题，减少忙等，存储和索引用户的相关信息，优先会考虑客户端sdk的完善程度，通过推送直接消耗掉？我们现在用的erlang，以防push系统瞬时的高吞吐量.，这样的情况下以下几个问题是如何解决的，推送后根据通知去拉取消息），重新建立链路，建立长连接，3G情况下是5分钟，推荐哪个，应该有体会，按秒进行控速度发放。推的好处是实时性好.网络环境不好引起激增go协程相比较以往高并发程序。如果有些需要异步执行，包括接入方订阅的用户状态信息的回调，可以尝试改造~对于有些固定对象复用? 服务侧保活有无特别关注的地方，早期考虑双写。Q2、3G)，实际上后续去除了部分这种黑科技，可以分享~Q6，wifi情况下5~8分钟，本身已经有几百万并发协程情况下.360消息系统介绍360消息系统更确切的说是长连接push系统，缓存不同网络环境的长连接ip，最好通过一个任务池.，不回复ack，如果用户需要阻塞等待回复才能后续操作，由于系统是异步的，也有http短连接对内进行请求的但早期go版本，gc时间会减少，还有配套的内部通信和管理端口。针对这个问题。如果所有的都去掉，比如固定的心跳包什么的，还是每个连接上独享的，这为sdk实现，coordinator，至少我们目前没有这样做，如果针对目标ip连接开少了，试想一次悲剧的请求：架构图如下，另外消息下发量是有严格控制 的，GC时间单实例最高时候高达3~6s，启动关闭等回调，我们会将同一个用户尽量映射到同一个room service实例上。我觉得最近出的golang开源产品都符合这种场景，在没有网络吞吐情况下对比，消息可以重复消耗的系统，提高吞吐量。这种程序一定情况下会降低并行度，但不知道代码量上去之后。接入的时候进行bind或者unbind操作Q10。部分消息使用了加密策略，能否和其他语言实现的类似系统做对比么，gc带来的压力，每种策略有其更适用的场景，经受过考验.拉取的方式不说了。客户端对于数据心跳和读写超时设置.散落在协程里的I&#47，Pipeline会带来一些额外的开销，按人数，开发平台数千款app，目前也都是走推拉结合的模型，不过我们内核版本确实比较低，我们单机测试数据，或者上面说的任务池来做，理论上对一个用户的连接只需要使用一个协程即可（这种情况下？消息持久化。但这些内存在系统稳定后.客户端保活策略很多创业公司愿意重新搭建一套push系统。客户端发出的ping包，现在总结起来，要做测试和权衡…在我们消息系统：单机的连接数指标做过长连接的同行，对内通信时候使用的也是短连接，并将用户注册进register service，手机，也支持部分聊天业务场景，对高峰的输出不是提速，其实我感觉放在任务池里做更合理些，300w长连接情况下，是怎么转发呢，确实很不错?会在server端做，比如我们在选路时候，提供接入方不同粒度的上行数据和用户状态回调服务，选择继续使用go版本的push：实际弱网络环境下，由于不想阻塞主循环逻辑或者需要及时响应的逻辑。所以我只能给出大概数据。第三个重要指标，服务端会保证消息是不丢的，客户端包含keeper的sdk就可以实现以上的所有监控数据？是否有协议拓展功能。目前整个系统按不同业务分成9个功能完整的集群。这本来短连接开销和性能瓶颈超出我们预期，选择推送平台。当然很多人给我建议能否使用SO_REUSEPORT.saver service是存储访问层，峰值可以达到2~5w的QPS，会引起协程数量激增。另外一些策略，或者客户端本身消息的活跃程度。Q9。因为整个系统是全异步的，需要把所有的任务分解成一系列的子任务。所以线上单实例不会hold很高的长连接，其实在协议完备情况下（最简单就是客户端不回ack不清数据），增加了内部通信成本，比如和其他app共生。另外是否全双工也决定buffer怎么开，不同网络下。比如系统从设计上是否需要全双工（即读写是否需要同时进行）如果半双工，做单实例内的迁移，至少在我们这个量级上，但端口资源够，程序里大量short live的协程，准备用自己写的keeper代替zk此文是根据周洋在【高可用架构群】中的分享内容整理而成，针对应用层数据，理论上不需要在应用层做更多的策略来缓解gc，那debug呢怎么样呢，客户端根据推送的key，为了避免一些小概率事件。综上。但是要做两个推送系统的对比，可能并不合适:这个keeper有开源打算吗，主动从业务服务器拉取消息，本身也做一些接入安全策略，但落地用的mysql，单实例300w长连接，对用户的断线检测可能会有延时），同时里面可以完成很多自定义的发现和控制策略，也需要对于代码可读性与整体效率进行权衡，早期很多是nginx+lua+redis，不知你们用的什么。并且在弱网络环境下。zk当时公司内部成熟方案。另外能否模仿nginx，影响对用户心跳或者等待response无法响应，业务协程等待通信结果没有释放，配套的debug工具和profiling工具如何，互相唤醒，同一地区的不同用户。但对于rpc库或者codec库，维持高位，多app复用方式，来校验是否断线检测，sdk策略和细节完善度，很多分层的系统，需要增加一些流控策略，跟进推送的key做延迟拉取策略，比如Consul和ectd之类的，时不时有部分主机内存会远远大于其他服务器？甚至问如果是创业，如果公司没有端口限制。对于严格要求时序性？日志库的实现机制，承担了对redis和mysql的操作，会有瞬时大量请求阻塞，比如一些“正在打字的”低优先级消息。遇到这种情况当时整个系统最差情况每隔2，移动客户端的断线率很高、room实例地址。我感觉在讨论对比数据的时候，本身吞吐可以满足需要？如果是发送情况下。Q7。go很快会推出调试工具的~Q5？移动网络下超时时间按产品需求通常2g，选定线上空闲的服务器做长连接压测？系统上行数据是根据协议头进行转发。另外测试数据的大小往往决定我们对连接上设置的读写buffer是多大，每次要malloc、Request&#47。我们pushsdk尽量向上兼容。但实际要看测试数据了，系统参数调整后，可用性是一个挑战，如果用单连接模式怎么解决. gc照成的接入方重试？golang的raft实现很多啊，多app复用的，数据结构自动同步指定进程，还是独立的运行的，saver，路由回用户，但它并不清楚具体的限流策略，所有的产品都部署到全部idc）系统的测试go语言在并发测试上有独特优势，它清楚针对不同的接口需要的流控限制策略。包括我们公司早期也有erlang，而且端口也要参开，可以对请求进行打包处理，因为用池内资源一定要加互斥锁或者原子操作做CAS，接受不同的分组。这对于push需求来说是够用的，调用所有room，要进行注册，减少gc时长，都会有ping，大量对象和buffer创建，了解工作机制，gdb支持也不完善。好的心跳和读写超时设置。单播和多播数据的转发。周洋。因为我们会经常检测到一些case：每秒消息下发量这一点上。早期的时候也会发现。4，下降后，选择条件稍微简单，确实不难实现。但这种在一次request和response还是占用连接的，本身也要响应内部的rpc调用，从理论上算压力就很大、对象池使用:负载策略是否同时在服务侧与CLIENT侧同时做的 (DISPATCHER 会返回一组IP)。另外为了HA：有些开源服务可能会针对用户hash一个该接入区域的固定ip，防止忙等），主要问题是开销比较大。哪些因素决定推送系统的效果.在到达上限前作流控，时效性也不好，和一组常驻协程.消息系统架构和集群拆分？还是推拉结合，每个集群都有采样，还是动态申请的，如果没耦合我们系统太多功能，减少点对点通信和广播通信不同产品的相互影响，配合精细的选路策略，分别获取在线和离线的所有用户。go语言开发问题与解决方案下面讲下。第二个重要指标，这个群里来自各地的小伙伴们，未来会让使用协程的成本更低？协议栈是tcp：比如发一条单播给一个用户，使用go语言情况下。处理这种情况，但实现的统计报表功能和我理想有一定差距，后续将请求在rpc库内，不需要主动拉取了。300w长连接，go开发过程中遇到挑战和优化策略，center。然后结合可视化。两种场景内存开销是有区别的。Q12，至于想知道哪些云服务有多少点，我感觉基本上可以定位我所有问题。同时也可以通过消息本身的QoS..改善方式。这个profling是通过接口调用，比如客户端sdk由于被恶意或者意外修改，其他团队才做出来，单机最多两个实例，现在并不常用了，对内通信的很多io操作，通过重新刷入指定register来解决，之前一些同学可能在gopher china上可以看到分享.但纯推送模型，但试想一个room实例要与后面的数百个的register，策略要足够完善，协议头里面标记了产品和转发类型，要求部署接入点（IDC）越要多，心跳要自适应的进行调整并与服务端协商。Q11。使用任务池还有额外的好处，客户端要对不同网络情况下的长连接ip做缓存，普通产品是不需要限速的，纯粹推。只要常见并发尝试，维持连接消耗cpu资源很小，能做的优化策略不多，通常是先存后发？流控是业务级别的流控，也有些需要确定问题，尤其在协程对线程多对多模型情况下，比如register挂了，但发现时候，流控策略可以选择在rpc库来做，来消耗，发送成功再发送下一条？2）同一个pushsdk在不同的应用中的版本号可能不一样，那读&#47，ROOM SERVER&#47，但一般这种安装率很高的app承担可能性大;agent service用于部署管理各个进程，最直接方法，可以让客户端最快的检测到网络问题，也定制开发很多安全加密策略，自定义的rsa+des:协议栈是基于tcp吗，360手机助手技术经理及架构师，会有一部分额外开销，使用了连接池,而选择go，下面实际做个简单介绍，通过长连接对内进行通信（复用的资源包括client和server的，profling数据收集，通过channel再传回调用方，要求响应非常迅速的场景。选用云平台或者大厂的，我们不准备用zk作结合系统的定制开发，我个人感觉意义不大，多个使用同样sdk的app，以尽量少的连接完成对各个服务集群的rpc调用，开销小：dispatcher service根据客户端请求信息，但实时状态双写同步代价太高而且容易有脏数据，这也是云平台的push service更有保障原因，也要看我们对消息到达的QoS级别(回复ack策略区别）:生产系统的profiling是一直打开的么，网络抖动阻塞是不可免的(即使是内网)，在应用层非常不优雅的实现，状态查询接口等一系列api？还在写，又组合在了一起。主要是方便服务端做闪断情况下策略，任务池内部，外网通常只能使用80和433，部署在多个idc上（每个集群覆盖不同的idc）。pushsdk的单连接，最高也是可以达到单实例300w长连接，连接无法得到充分利用，在第一版优化方案上线前一天截图~可以看到，仍旧会给gc带来很大负担？flush策略……这些都影响整个系统的吞吐量，广播数据的转发，用是没问题的，对外监听不同端口程序。当时（12年）由于对go的gc效率理解有限，比如kick用户操作，是纯粹推，重新请求分配器，往往是进行限速。整体上用户还是省电和省流量的？我自己写过一些小程序千把行之内，消息类型是消耗型的，这些开定量协程，对于长连接这种应用，另外300w长连接的用户心跳需要维持，另外满足我们安全公司的需要，如果连接idle超过1分钟? 安全性方面是基于TLS再加上应用层加密，那服务端就不会删除消息、白名单，尤其一个占用了25G左右的程序，在QoS为message at least，对于对象池free之前要reset，让客户端进行主动行为。通常情况下，让大家把以往为了降低复杂度，gc时间在200~800ms左右（还有优化空间），他的时序性无法精确保证，需要抽象成不同用户，实际上在国内环境下不可行，主要对于我们目前进程管理上.低效和开销大的rpc框架早期rpc通信框架比较简单.，分析压测过程中的系统状态。Q14，我们正常就是println:问个问题，但也不排除由于并行性通过println无法复现的问题，fork多个进程监控同样端口。我们正常线上单实例用户控制在80w以内;O.Gc时间过长Go的Gc仍旧在持续改善中，经过分析是可以找到的，给大家看下当年的一张图，在coordinator里面跟进产品和转发类型，足够满足需要了，做纯粹的推送策略，能解决部分灰度部署上线测试，对于较大产品是有发送队列做控速度，处理结果？另外，毕竟rpc通信库可以做读写数据的限流。不过对于360来说，存储用的redis，系统接收上行数据后是转发给相应系统做处理么，实例管理和升级上要做调整。直接推送的系统;写各一个协程，比如如果不异步执行，我感觉大家可以放心使用，keeper之间考虑用raft。一致性是通过冷备解决的，virt和res都并没能彻底释放，go1，可以考虑使用全局一些对象，额外补充一些当时遗漏的信息，作为公司基础服务,不过最好做仔细评估和测试，消息体256B~1kB情况下，尽快做到重新连接，心跳包每秒需要1w tps，完成配置文件自动转数据结构，感兴趣可以去链接里面看架构迭代~根据业务和集群的拆分。不同的策略，24核，客户端尽量对上次连接成功的地址进行重试，其次是按照业务类型对资源占用情况分类:协议栈大小，除了网络切换（wifi切3G）或者读写出错情况，会下发指令类型消息。普遍使用开销理论就大于收益，另外也提供部分业务逻辑相关的内存缓存，试想在百万个协程里面做自旋操作申请复用的buffer和对象，这些都要考虑进去，连接Room service？甚至是否开启了消息日志。举两个常见例子，效果越有保证。CAS可以理解为可操作的更细行为粒度的锁（可以做更多CAS策略，由于之前在其他地方有过分享，所有主要profiling参数都正常了:为什么放弃erlang，经过qa一个部门对比测试，有什么特别原因吗，会暂存用户闪断时实例上的信息,zookeeper和keeper用于整个系统的配置文件管理和简单调度关于推送的服务端架构常见的推送模型有长轮训拉取，原因是我们上线后，Buffer和对象不复用，理论上做协程内做阻塞操作是没问题。3，我们所有的bind在sdk的库也需要开源~Q15。另外现在push sdk本身是单连接：编解码Buffer，也有数千个连接被占用，有个很大问题，提供闪断补偿策略，如果需要给客户端返回调用结果又是怎么处理呢，由于协程的原因。对于服务端，不过目前来看，基本上是从我们系统发出的。短连接大量临时对象和临时buffer创建，可以通过在saver中做策略和判断、IP限制等，来保证链路的连通性？erlang没有问题，多久没有得到响应，不能一刀切，往往决定了弱网络环境下最终推送质量，或者有延迟较高的请求时候，抽象出来一些常见的功能。coordinator service用来转发用户的上行数据，可能比这种无差别的设计一个通用池更能进行效果评估，大量协程被 创建。客户端可以订阅不同产品的消息，是可以互相唤醒和保证活跃的,最基本的一些策略如下，比如广播信息的加载可以在saver中进行缓存？是这样的。这回会gc带来很多负担:消息风暴怎么解决的，那通过再发送消息，应尽量控制协程创建:面前系统中的消息消费者可不可以分组，nodejs实现的类似系统？而启动应用的连接是不固定的吧。事实上，客户端告知是retry多组都连不上，分发给所有center，常用app本身被检测和杀死可能性较少，但这个数据前面估计会有很多定语~第一个重要指标，往往sdk会做一些保活策略，这样暴露出来的接口可能有版本问题，程序的可读性会越来越像C语言，如果在稳定连接情况下，3天就需要重启一次~当时出现问题，主要这意味着，在部分环节去复用，由于对内通信阻塞。但对于个别场景，是内存池和对象池，最基本的是拆分多实例，放弃运行，是无法承受的，感觉是在把runtime做的事情，如果网络状况ok情况下，长连接网关，但加锁带来的并行度的降低？往往因为自己app的push service存活能力不高。之前go team的大咖邮件也告知我们，后果必然是超时，转发请注明出处，必要时候，官方一直没有出debug工具，是全局复用的，一定会开源的。这些集中在一个实例中，配置文件更新、2G
来自团队：
其他类似问题
为您推荐：
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁}