hhvm wordpress成都网站推广优化公司

当前位置： 首页 > news >正文

hhvm wordpress,成都网站推广优化公司,出入成都最新通知今天,wordpress文章更新软件1000W长连接#xff0c;如何建立和维护#xff1f;千万用户IM 架构设计 在40岁老架构师 尼恩的读者交流群(50)中#xff0c;最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格#xff0c;遇到很多很重要的架构类/设计类…1000W长连接如何建立和维护千万用户IM 架构设计 在40岁老架构师 尼恩的读者交流群(50)中最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格遇到很多很重要的架构类/设计类的场景题 1.千万用户规模 IM 架构设计请说出你的方案 2.1000万长连接如何建立和维护 最近有小伙伴在面试 美团又遇到了 IM 架构问题。小伙伴支支吾吾的说了几句面试挂了。 所以尼恩给大家做一下系统化、体系化的梳理使得大家内力猛增可以充分展示一下大家雄厚的 “技术肌肉”让面试官爱到 “不能自已、口水直流”然后实现”offer直提”。 当然这道面试题以及参考答案也会收入咱们的 《尼恩Java面试宝典PDF》V171版本供后面的小伙伴参考提升大家的 3高 架构、设计、开发水平。 最新《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF请关注本公众号【技术自由圈】获取回复领电子书 一、IM的重大价值 1、IM的广泛使用场景 即时通信Instant Messaging简称 IM是一种通过网络进行实时通信的系统允许用户之间快速传递信息。 无论是文字消息、文件还是语音和视频交流IM 系统都能即时响应。 即时通信IM功能模块具有广泛的应用场景可以集成到多种系统中以增强沟通和协作能力。 以下是一些常见的即时通信IM应用场景

1. 企业内部沟通系统 协作工具如 Slack、Microsoft Teams 等为团队提供即时消息、文件共享、视频会议等功能提升工作效率。企业管理系统ERP、CRM整合 IM 功能方便员工快速交流、协作以及与客户或合作伙伴沟通。
2. 社交平台 社交网络如 Facebook、Twitter 等可以通过 IM 功能让用户私下交流或创建群组讨论。在线社区和论坛提供用户之间的即时消息功能增强互动性和用户粘性。
3. 电子商务平台 客户支持如 Shopify、Amazon 等电商平台通过 IM 实现客户与客服的实时沟通解决售前咨询或售后服务问题。买卖双方沟通买家与卖家可以直接通过 IM 沟通协商交易细节。
4. 教育系统 在线学习平台如 Coursera、Udemy师生之间可以通过 IM 进行实时交流辅导和答疑。校园管理系统学校内部系统中师生或学生之间可以通过 IM 进行联系安排活动或布置作业。
5. 医疗系统 远程医疗患者与医生之间可以通过 IM 进行初步沟通预约咨询或远程诊断。医院管理系统医院内部工作人员之间可以通过 IM 实时沟通协调工作和安排。
6. 在线游戏 多人在线游戏如 MMORPG、MOBA 类游戏通过 IM 实现玩家之间的实时沟通和策略讨论。游戏社交平台玩家之间可以通过 IM 进行交流、组队或分享游戏经验。
7. 金融系统 在线银行和支付系统如支付宝、微信支付通过 IM 功能实现用户与客服的沟通解决支付问题或账户管理。投资和交易平台投资者之间或与金融顾问之间通过 IM 进行市场讨论和交易建议交流。 这些 IM 功能模块能够融入不同系统极大地提升了用户的交互体验和系统的服务能力。 2、IM的巨大学习价值 由于IM的广泛使用场景广泛所以im的学习价值巨大。 另外im也是面试的重点和难点。 3、技术要点 1、网络传输协议 ​ IM系统传输即时消息无外乎使用UDP、TCP、基于TCP的HTTP这几种协议中的一种或几种 UDP协议实时性更好但是如何处理安全可靠的传输并且处理不同客户端之间的消息交互是个难题实现起来过于复杂HTTP协议属于扩展支持数据传输量大TCP协议如果有海量用户的需求。如何保证单机服务器高并发量如何做到灵活扩展的架构。 2、数据通信格式协议 自定义二进制信息体积小占用带宽低传输效率高缺点是处理不同客户端之间的消息交互较复杂。提供序列化和反序列化库的开源协议protocol buffers json Thrift。是一种流行的通用数据格式扩展相当方便序列化和反序列化相当方便。文本化协议序列化反序列化容易库支持可视化强缺点相对于二进制存储占用体积大 3、如何保证实时消息的有序性、可用性 IM中消息的投递中要保证发送方发送顺序与接收方展现顺序一致。IM中如何保证在线实时消息的可靠投递即消息的不丢失和不重复。TCP 自带TCP Keepalive 无法满足需求。 4、如何处理群发消息以及离线消息 5、如何进行消息持久化 6、如何避免数据中心级故障 二10万用户-100万用户-1000万用户 的架构演进 10万用户100万用户1000万用户存储架构MySQL 主备Redis 主备MySQL 主备 Redis cluster MongoDBMySQL 主备 Redis cluster HBASE存储平台接入架构2台 Nginx 负载均衡2台 Nginx/LVS 负载均衡三级缓存2台 Nginx/LVS 负载均衡三级缓存 / 多数据中心部署可扩展架构2个单体架构/直连3个服务微服务/异步广播3个服务微服务/异步精准路由高可用MySQL 主备跨机房复制只保证基础数据不丢失同城双中心同城双活/异地双活大数据架构MongoDB大数据平台 flink ES HBASE基础设施快速扩展辅助需求全面完善基础技术 三10万用户im架构 1、多协议支持 ​ 支持TCP、WebSocket。使用 Netty 和 Protobuf 实现高性能IM 通信模块能够结合 Netty 的高性能网络通信框架和 Protobuf 的高效序列化机制构建一个高效、可扩展的即时通信系统。 要构建一个高性能的 IM 通信模块使用 Netty 和 Protobuf 并支持 TCP 和 WebSocket 协议需要设计一个能够处理多种协议、灵活扩展、并且能够保证低延迟和高吞吐量的架构。 TCP 通信 ChannelPipeline 配置通过 Netty 的 ChannelPipeline 配置解码器ProtobufDecoder、编码器ProtobufEncoder和自定义的 ChannelHandler。TCP Server通过 ServerBootstrap 启动 TCP 服务绑定端口并监听连接。 WebSocket 通信 HTTP 协议升级首先通过 HTTP 进行握手然后升级为 WebSocket 协议。 Netty 提供了 WebSocketServerProtocolHandler 来处理协议升级。 消息处理在升级为 WebSocket 后使用 WebSocketFrame 来传递消息再通过 Protobuf 进行编解码。 WebSocket Server与 TCP 类似使用 ServerBootstrap 启动并配置 WebSocket 服务。
   
8. 消息编解码设计 消息编解码利用 Protobuf 进行消息的序列化和反序列化减少数据传输的大小并保证高效的数据传输。 Protobuf 生成器通过 .proto 文件定义消息结构并使用 protoc 编译生成相应的 Java 类。Protobuf 编解码 ProtobufDecoder将收到的二进制数据解码为 Protobuf 消息对象。ProtobufEncoder将消息对象编码为二进制格式准备发送。
   
9. 用户管理与消息路由 用户连接管理 使用数据结构如 ConcurrentHashMap来管理用户的连接映射跟踪每个用户的 Channel 实例。使用redis 来管理 user 和node 的映射关系跟踪每个用户的 node 实例。多设备支持如果一个用户可以有多个设备在线需要设计一个映射来跟踪每个设备的连接。 消息路由与分发 实现消息的路由逻辑根据接收者的 ID 查找对应的 Channel 并将消息发送。支持单播、组播群聊和广播消息。
   
10. 心跳机制 TCP 心跳通过 Netty 的 IdleStateHandler 检测连接的空闲状态如果超过一定时间没有读写操作可以发送心跳包或断开连接。WebSocket 心跳使用 WebSocket 的 PING/PONG 帧来维持连接活跃状态。 5.高可用性设计 实现服务的集群化部署使用 ZooKeeper 等工具进行服务注册和发现保证集群的高可用性。 6扩展性与容错性设计 分布式架构 im 服务实例可以水平扩展设计 Router 服务实现im 服务实例 直接的 负载均衡。 负载均衡架构
    ​ 同时可以把im节点分组通过ng负载均衡保证 接入层的高可用性。 710万用户im架构与实操 10万用户im架构与实操 具体请参考尼恩的IM实操视频。 四100万用户im架构如何进行升级 1、高扩展架构功能的细粒度、分布式解耦 在构建高性能 IM 系统时将不同的功能模块解耦是一个关键的设计策略可以提高系统的可维护性、可扩展性和容错能力。 通过将 IM 服务拆分为多个独立的微服务每个服务专注于特定的功能模块能够更好地分配资源、隔离故障并简化开发和部署流程。 使im服务node的不同功能模块解耦如连接管理服务、业务逻辑服务等。 连接管理服务职责 管理用户的长连接处理 TCP 和 WebSocket 连接的建立与断开。维护用户的在线状态管理链接的 heartbeat 心跳。连接管理服务可以组成集群每个连接管理节点可以维护一部分用户的连接分片管理并通过一个注册中心如 ZooKeeper来协调和管理节点间的负载。 logic 业务逻辑 服务 包括 消息处理服务用户认证服务群组管理聊天记录管理消息过滤等。 2、基于Rocketmq做异步消息推送 1. 架构设计 生产者-消费者模型IM 系统的消息生产者如发送消息的客户端或服务将消息推送到 Rocketmq主题中消费者如消息接收者的客户端或服务从 Rocketmq中拉取消息进行处理。分区与副本Rocketmq主题可以分为多个分区分区内的消息是有序的同时为了实现高可用性每个分区可以有多个副本分布在不同的 Rocketmqbroker 上。
11. 消息生产 消息队列设计根据业务需求设计 Rocketmq主题的分区策略。例如可以按照用户 ID 或聊天会话 ID 来进行分区以保证相关消息的有序性。消息格式设计消息的序列化格式如 JSON、Avro、Protobuf并确保消息内容包括必要的元数据如消息 ID、时间戳、发送者和接收者 ID。
12. 消息消费 消费者组接收消息的消费者可以被组织为一个消费者组Rocketmq会将主题的分区分配给消费者组内的不同消费者确保每个分区的消息只被一个消费者处理避免重复消费。消费确认与偏移量管理消费者在处理消息后需要提交消费偏移量Offset到 Kafka以便在重启或故障恢复时从正确的位置继续消费。可以选择自动提交自动提交可能有消息丢失的风险或手动提交需要在消息处理完成后手动提交保证消息处理的准确性。
13. 消息持久化与顺序性 消息持久化Rocketmq自带持久化机制消息可以保留一定时间可配置即使消费者临时不可用消息也不会丢失。消息顺序如果需要保证消息的顺序性可以将相关消息如同一会话中的消息发送到同一分区中。
14. 故障处理与重试机制 消息重试在消息处理失败时可以将消息重新放回 Rocketmq队列或记录到专用的失败队列进行后续重试或人工处理。幂等性处理在消费端实现幂等性逻辑确保消息即使被多次处理也不会引发不一致问题。 3、100万用户im架构总体架构 4、ConnectManager服务用户代理服务器用于客户端的连接 客户端首先连接到ConnectManager服务ConnectManager 发送消息到 rocketmq 。 2logic 业务逻辑 服务 收到消息进行 消息的处理 3如果是收到登录的消息logic 校验用户的合法性 如果 校验通过logic 会返回一个 token 给 rocketmq 这是一个广播消息 该 token 成为该连接的安全通讯的令牌 ConnectManager 收到令牌标识登录成功并且给客户端正确的响应 后面可以开始正常的聊天消息处理 客户端接下来可以发心跳包给ConnectManager ConnectManager 会转发到 rocketmq logic 业务逻辑处理心跳包。
    7 客户端发送消息给ConnectManager ConnectManager 会转发到 rocketmq logic 业务逻辑 服务 将MQ的消息处理完成后 处理结果发送到 rocketmq ConnectManager 再将其转发到对应的客户端。 8 这里的rocketmq 下行消息是广播模式 同一个下行的消息会发送给所有的ConnectManager ConnectManager 收到属于当前节点的回复消息再将其转发到对应的客户端如果 收到消息不是当前节点的消息ConnectManager 抛弃。 5、logic 业务逻辑 服务主要业务处理模块 1、订阅rocketmqmq处理Comet对Logic的远程RPC调用的处理如用户登录注册等。 2、启用rest 服务监听business 微服务上 B端推送的IM的消息将这些聊天相关的业务发生到 Kafka。 6、100万用户im架构中的跨node的会话路由 1这里分为local-session 本地会话 、Distrubute-session 分布式会话。 ​ 其中local-session使用map来维护本地会话。分布式session 使用redis 维护全局的会话映射关系分布式会话映射关系清晰但是模式比较重。 100万用户im, 其实使用 local-session 本地会话 其实就可以了。跨node的会话路由通过Rocketmq做广播消息解决。 2跨node的会话路由100W连接的场景可以简单的使用的事件广播由各节点自行判断是否持有local-session 会话。 3当然当有1000W级链接 node节点较多时所有节点均被广播资源浪费。 跨node的会话路由 整体流程如下 1客户端与网关的任何一个ConnectManager节点建立长连接节点会将其加入到内存中的长连接队列。客户端会定期向服务端发送心跳消息若超过设定时间还未收到心跳则认为客户端与服务端的长连接已断开服务端会关闭连接清理内存中的会话。 2当业务系统需要向客户端推送数据时通过提供的HTTP接口将数据发送至服务 logic服务 。 3 logic服务 在收到推送请求后服务会将消息写入RocketMQ。 4ConnectManager 服务作为消费者以广播模式消费消息所有ConnectManager 节点都能收到消息。 5ConnectManager节点在收到消息后会判断推送的消息目标是否在其内存 local-session map中维护的长连接队列里如果存在则通过长连接推送数据否则直接忽略。 7、100万用户的数据存储架构 存储平台 1.SQL 平台2.NoSQL 平台3.文件存储。 大数据平台 1.离线处理2.在线处理3.推荐系统。 这里的NoSQL 平台 使用MongoDB 具体的架构方案与实操请参见 100亿级数据存储架构MYSQL双写 HABSE Flink ES综合大实操 五1000万用户im架构如何再造升天 1、高扩展架构更进一步的 功能的细粒度解耦, 实现无限可扩展的架构 在构建1000w用户高性能 IM 系统时将不同的 logic 功能模块解耦是一个关键的设计策略可以提高系统的可维护性、可扩展性和容错能力。 通过将logic 服务拆分为多个独立的微服务每个服务专注于特定的功能模块能够更好地分配资源、隔离故障并简化开发和部署流程。 logic 业务逻辑 服务负责 消息处理服务 消息过滤等。
    UserAuth 服务负责 用户认证服务 group 服务负责 群组管理 storage 服务负责 聊天记录管理 其他服务负责 风控等等。 不同的服务使用不同的消费者group 消费者组接收消息的消费者可以被组织为一个消费者组Rocketmq会将主题的分区分配给消费者组内的不同消费者确保每个分区的消息只被一个消费者处理避免重复消费。消费确认与偏移量管理消费者在处理消息后需要提交消费偏移量Offset到 Kafka以便在重启或故障恢复时从正确的位置继续消费。可以选择自动提交自动提交可能有消息丢失的风险或手动提交需要在消息处理完成后手动提交保证消息处理的准确性。 2、1000万用户im架构中的跨node的会话路由 在处理大规模连接和高并发的场景时跨节点的会话路由是一个关键的技术挑战。 1000万用户 跨node的会话路由通过Rocketmq做广播消息会造成网络资源浪费。 这里需要用到 Rocketmq集群消息 Distrubute-session 分布式会话。 1这里使用 Distrubute-session 分布式会话。 local-session使用map来维护本地会话。但这里还要结合 使用 分布式session 使用redis 维护全局的会话映射关系分布式会话映射关系清晰但是模式比较重。 2跨node的会话路由1000W连接的场景可以采用的 Rocketmq集群消息 每个节点的消息发到这个节点对应的topic。 3 Rocketmq Topic设计 为每个节点创建一个独立的Topic确保消息可以定向发送到正确的节点。考虑使用分区Partition来提高并发处理能力。 4 Producer 设计 可以根据会话ID或其他业务标识符来确定node 对应的topic。配置Producer 以发送消息到正确的Topic。 5 Consumer配置设计 每个node 节点上的Consumer订阅对应的Topic。 根据业务需求配置并发数量和消费策略。
    3、如何避免数据中心级故障 数据中心级故障 故障的原因很多比如 在 IM 系统中实现异地多活Active-Active架构并确保消息数据同步是为了提高系统的可用性和容灾能力同时降低网络延迟对用户体验的影响。 异地多活意味着多个数据中心在不同的地理位置同时提供服务这些数据中心之间需要保持数据的一致性尤其是消息数据的同步。以下是实现异地多活架构及消息数据同步的关键点和设计策略。 异地多活Active-Active 架构设计原则 全局分布式架构将 IM 系统部署在多个地理位置不同的数据中心每个数据中心都能够独立处理用户的连接和消息但所有数据中心之间需要实现高效的数据同步和一致性保障。数据分区与路由可以根据用户的地理位置将其连接路由到离用户最近的数据中心减少网络延迟。同时系统需要能够处理跨数据中心的消息传递。高可用性和容错性任何一个数据中心的故障不应该影响整体服务的可用性其他数据中心应当能够无缝接管业务。 异地多活Active-Active 数据同步机制 消息队列同步使用分布式消息队列Rocketmq在数据中心之间传递消息。每个数据中心的消息队列 设置sync-Storage 微服务负责将本地消息复制到其他数据中心保证消息的一致性。 数据库同步 使用分布式数据库如 Cassandra、CockroachDB或数据库复制技术如 MySQL 的 GTID 复制、主从复制来实现数据同步。 这里采用了方式1 每个数据中心 设置sync-Storage 微服务负责将本地消息复制到其他数据中心保证消息的一致性。 4、1000万用户的数据存储架构 存储平台 1.SQL 平台2.NoSQL 平台3.文件存储。 大数据平台 1.离线处理2.在线处理3.推荐系统。 这里的NoSQL 平台 使用 hbase 具体的架构方案与实操请参见 100亿级数据存储架构MYSQL双写 HABSE Flink ES综合大实操 说在最后有问题找老架构取经 1000万长连接如何建立和维护 千万用户IM 架构设计
    以上的内容如果大家能对答如流如数家珍基本上 面试官会被你 震惊到、吸引到。 最终让面试官爱到 “不能自已、口水直流”。offer 也就来了。 在面试之前建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》里边有大量的大厂真题、面试难题、架构难题。 很多小伙伴刷完后 吊打面试官 大厂横着走。 在刷题过程中如果有啥问题大家可以来 找 40岁老架构师尼恩交流。 另外如果没有面试机会可以找尼恩来改简历、做帮扶。 遇到职业难题找老架构取经 可以省去太多的折腾省去太多的弯路。 尼恩指导了大量的小伙伴上岸前段时间刚指导一个40岁被裁小伙伴拿到了一个年薪100W的offer。 狠狠卷实现 “offer自由” 很容易的 前段时间一个武汉的跟着尼恩卷了2年的小伙伴 在极度严寒/痛苦被裁的环境下 offer拿到手软 实现真正的 “offer自由” 。 另外尼恩也给一线企业提供 《DDD 的架构落地》企业内部培训目前给不少企业做过内部的咨询和培训效果非常好。 尼恩技术圣经系列PDF 《NIO圣经一次穿透NIO、Selector、Epoll底层原理》《Docker圣经大白话说Docker底层原理6W字实现Docker自由》《K8S学习圣经大白话说K8S底层原理14W字实现K8S自由》《SpringCloud Alibaba 学习圣经10万字实现SpringCloud 自由》《大数据HBase学习圣经一本书实现HBase学习自由》《大数据Flink学习圣经一本书实现大数据Flink自由》《响应式圣经10W字实现Spring响应式编程自由》《Go学习圣经Go语言实现高并发CRUD业务开发》 ……完整版尼恩技术圣经PDF集群请找尼恩领取 《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》PDF请到下面公号【技术自由圈】取↓↓↓