Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 409, comments - 13, trackbacks - 0, articles - 0

2012年9月15日

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第33 期。

[- 1 -] IM开发技术学习:揭秘微信朋友圈这种信息推流背后的系统设计

[链接] http://www.52im.net/thread-3675-1-1.html

[摘要] 本文将重点讨论的是“关注”功能对应的技术实现:先总结常用的基于时间线Feed流的后台技术实现方案,再结合具体的业务场景,根据实际需求在基本设计思路上做一些灵活的运用。


[- 2 -] 阿里IM技术分享(六):闲鱼亿级IM消息系统的离线推送到达率优化

[链接] http://www.52im.net/thread-3748-1-1.html

[摘要] 本文将要分享的是闲鱼IM消息在解决离线推送的到达率方面的技术实践,内容包括问题分析和技术优化思路等,希望能带给你启发。


[- 3 -] 阿里IM技术分享(七):闲鱼IM的在线、离线聊天数据同步机制优化实践

[链接] http://www.52im.net/thread-3856-1-1.html

[摘要] 本篇将要分享的是闲鱼IM系统中在线和离线聊天消息数据的同步机制上所遇到的一些问题,以及实践性的解决方案。


[- 4 -] 探探的IM长连接技术实践:技术选型、架构设计、性能优化

[链接] http://www.52im.net/thread-3780-1-1.html

[摘要] 本文将要分享的是陌生人社交应用探探的IM长连接模块从技术选型到架构设计,再到性能优化的整个技术实践过程和经验总结。


[- 5 -] IM开发干货分享:浅谈IM系统中离线消息、历史消息的最佳实践

[链接] http://www.52im.net/thread-3887-1-1.html

[摘要] 本文将基于IM消息系统的技术实践,分享关于离线消息和历史消息的正确理解,以及具体的技术配合和实践,希望能为你的离线消息和历史消息技术设计带来最佳实践灵感。


[- 6 -] IM开发干货分享:IM客户端不同版本兼容运行的技术思路和实践总结

[链接] http://www.52im.net/thread-4202-1-1.html

[摘要] 本文将基于笔者的IM产品开发和运营实践,为你分享如何实现不同APP客户端版本与服务端通信的兼容性处理方案。


[- 7 -] 字符编码那点事:快速理解ASCII、Unicode、GBK和UTF-8

[链接] http://www.52im.net/thread-1693-1-1.html

[摘要] 字符编码是计算机技术的基石,对于程序员来说尤其重要,字符编码的知识是必须要懂的。


[- 8 -] IM开发基础知识补课(八):史上最通俗,彻底搞懂字符乱码问题的本质

[链接] http://www.52im.net/thread-2868-1-1.html

[摘要] 对于乱码这个看似不起眼,但并不是一两话能讲清楚的问题,是很有必要从根源了解字符集和编码原理,知其然知其所以然显然是一个优秀码农的基本素养,所以,便有了本文,希望能帮助到你。


[- -]  史诗级计算机字符编码知识分享,万字长文,一文即懂!

[链接] http://www.52im.net/thread-4210-1-1.html

[摘要] 前一阵跟同事碰到了字符乱码的问题,了解后发现这个问题存在两年了,我们程序员每天都在跟编码打交道,但大家对字符编码都是一知半解:“天天吃猪肉却很少见过猪跑”,今天我就把它彻底讲透!


[- 10 -] 百度统一socket长连接组件从0到1的技术实践

[链接] http://www.52im.net/thread-4359-1-1.html

[摘要] 本文旨在探讨socket长连接技术在移动端的实践,并以iOS端为例,重点分享了百度在实现统一socket长连接组件过程中的技术选型和整体架构设计逻辑。并结合IM即时通讯聊天应用案例,展示长连接组件是如何在移动应用领域为类似业务场景提供解决方案的。


[- 11 -] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

[链接] http://www.52im.net/thread-4470-1-1.html

[摘要] 本文将介绍淘宝 APP 统一网络库演进的过程,讲述如何围绕体验持续构建南北向从监测到加速一体化的终端网络架构,通过构建 NPM 弱网诊断感知能力,落地原生多通道技术/多协议择优调度手段,贴合厂商附能网络请求加速,实现去 SPDY 及规模化 IPv6/H3 协议簇的平滑过渡,为用户提供弱网更好、好网更优的 APP 加载浏览体验,支撑业务创造更多的可能性。


[- 12 -] 揭秘企业微信是如何支持超大规模IM组织架构的——技术解读四维关系链

[链接] http://www.52im.net/thread-4471-1-1.html

[摘要] 本文将摘取企业微信的其中一个技术分支——IM体系之下的“关系链”内核要素,为你揭秘企业微信是如何支持超大规模IM组织架构的。


👉52im社区本周新文:《长连接网关技术专题(九):去哪儿网酒店高性能业务网关技术实践》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2024-02-22 12:13 Jack Jiang 阅读(33) | 评论 (0)编辑 收藏

本文由去哪儿网技术团队田文琦分享,本文有修订和改动。

1、引言

本文针对去哪儿网酒店业务网关的吞吐率下降、响应时间上升等问题,进行全流程异步化、服务编排方案等措施,进行了高性能网关的技术优化实践。

技术交流:

- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM

- 开源IM框架源码:https://github.com/JackJiang2011/MobileIMSDK备用地址点此

(本文已同步发布于:http://www.52im.net/thread-4618-1-1.html

2、作者介绍

田文琦:2021年9月加入去哪儿网机票目的地事业群,担任软件研发工程师,现负责国内酒店主站技术团队。主要关注高并发、高性能、高可用相关技术和系统架构。主导的酒店业务网关优化项目,荣获22年去哪儿网技术中心TC项目三等奖。

3、专题目录

本文是专题系列文章的第9篇,总目录如下:

  1. 长连接网关技术专题(一):京东京麦的生产级TCP网关技术实践总结
  2. 长连接网关技术专题(二):知乎千万级并发的高性能长连接网关技术实践
  3. 长连接网关技术专题(三):手淘亿级移动端接入层网关的技术演进之路
  4. 长连接网关技术专题(四):爱奇艺WebSocket实时推送网关技术实践
  5. 长连接网关技术专题(五):喜马拉雅自研亿级API网关技术实践
  6. 长连接网关技术专题(六):石墨文档单机50万WebSocket长连接架构实践
  7. 长连接网关技术专题(七):小米小爱单机120万长连接接入层的架构演进
  8. 长连接网关技术专题(八):B站基于微服务的API网关从0到1的演进之路
  9. 长连接网关技术专题(九):去哪儿网酒店高性能业务网关技术实践》(* 本文

4、技术背景

近来,Qunar 酒店的整体技术架构在基于 DDD 指导思想下,一直在进行调整。其中最主要的一个调整就是包含核心领域的团队交出各自的“应用层”,统一交给下游网关团队,组成统一的应用层。

这种由多个网关合并成大前台(酒店业务网关)的融合,带来的好处是核心系统边界清晰了,但是对酒店业务网关来说,也带来了不小的困扰。

系统面临的压力主要来自两方面:

  • 1)首先,一次性新增了几十万行大量硬编码、临时兼容、聚合业务规则的复杂代码且代码风格迥异,有些甚至是跨语言的代码迁移;
  • 2)其次,后续的复杂多变的应用层业务需求,之前分散在各个子网关中,现在在源源不断地汇总叠加到酒店业务网关。

这就导致了一系列的问题:

  • 1)业务网关吞吐性能变差:应对流量尖峰时期的单机最大吞吐量与合并之前相比,下降了20%
  • 2)内部业务逻辑处理速度变差:主流程业务逻辑的处理时间与合并之前相比,上涨了10%。
  • 3)代码难以维护、开发效率低:主站内部各个模块之间严重耦合,边界不清,修改扩散问题非常明显,给后续的迭代增加了维护成本,开发新需求的效率也不高。

酒店业务网关作为直接面对用户的系统,出现任何问题都会被放大百倍,上述这些问题亟待解决。

5、吞吐量下降问题分析

现有系统虽然业务处理部分是异步化的,但是并不是全链路异步化(如下图所示)。

同步 servlet 容器,servlet 线程与业务逻辑线程是同一个,高峰期流量上涨或者尤其是遇到流量尖峰的时候,servlet 容器线程被阻塞的时候,我们服务的吞吐量就会明显下降。

业务处理虽然使用了线程池确实能实现异步调用的效果,也能压缩同步等待的时间,但是也有一些缺陷。

比如:

  • 1)CPU 资源大量浪费在阻塞等待上,导致 CPU 资源利用率低;
  • 2)为了增加并发度,会引入更多额外的线程池,随着 CPU 调度线程数的增加,会导致更严重的资源争用,上下文切换占用 CPU 资源;
  • 3)线程池中的线程都是阻塞的,硬件资源无法充分利用,系统吞吐量容易达到瓶颈。

6、响应时间上涨问题分析

前期为了快速落地酒店 DDD 架构,合并大前台的重构中,并没有做到一步到位的设计。

为了保证项目质量,将整个过程切分为了迁移+重构两个步骤。迁移之后,整个酒店业务网关的内部代码结构是割裂、混乱的。

总结如下:

我们最核心的一个接口会调用70多个上游接口,上述问题:边界不清、不内聚、各种重复调用、依赖阻塞等问题导致了核心接口的响应时间有明显上涨。

7、 解决方案Part1:全流程异步化提升吞吐量

全流程异步化方案,我们主要采用的是 Spring WebFlux。

7.1选择的理由

1)响应式编程模型:Spring WebFlux 基于响应式编程模型,使用异步非阻塞式 I/O,可以更高效地处理并发请求,提高应用程序的吞吐量和响应速度。同时,响应式编程模型能够更好地处理高负载情况下的请求,降低系统的资源消耗。

2)高性能:Spring WebFlux 使用 Reactor 库实现响应式编程模型,可以处理大量的并发请求,具有出色的性能表现。与传统的 Spring MVC 框架相比,Spring WebFlux 可以更好地利用多核 CPU 和内存资源,以实现更高的性能和吞吐量。

3)可扩展性:Spring WebFlux 不仅可以使用 Tomcat、Jetty 等常规 Web 服务器,还可以使用 Netty 或 Undertow 等基于 NIO 的 Web 服务器实现,与其它非阻塞式 I/O 的框架结合使用,可以更容易地构建可扩展的应用程序。

4)支持函数式编程:Spring WebFlux 支持函数式编程,使用函数式编程可以更好地处理复杂的业务逻辑,并提高代码的可读性和可维护性。

5)50与 Spring 生态系统无缝集成:Spring WebFlux 可以与 Spring Boot、Spring Security、Spring Data 等 Spring 生态系统的组件无缝集成,提供了完整的 Web 应用程序开发体验。

7.2实现原理和异步化过程

上图中从下到上每个组件的作用:

  • 1)Web Server:适配各种 Web 服务, 监听客户端请求,并将其转发到 HttpHandler 处理;
  • 2)HttpHandler:以非阻塞的方式处理响应式 http 请求的最底层处理器,不同的处理器处理的请求都会归一到 httpHandler 来处理,并返回响应;
  • 3)DispatcherHandler:调度程序处理程序用于异步处理 HTTP 请求和响应,封装了HandlerMapping、HandlerAdapter、HandlerResultHandler 的调用,实际实现了HttpHandler的处理逻辑;
  • 4)HandlerMapping:根据路由处理函数 (RouterFunction) 将 http 请求路由到相应的handler。WebFlux 中可以有多个 handler,每个 handler 都有自己的路由;
  • 5)HandlerAdapter:使用给定的 handler 处理 http 请求,必要时还包括使用异常处理handler 处理异常;
  • 6)HandlerResultHandler:处理返回结果,将 response 写到输出流中;
  • 7)Reactive Streams:Reactive Streams 是一个规范,用于处理异步数据流。Spring WebFlux 实现了 Reactor 库,该库基于响应式流规范,处理异步数据流。

在整个过程中 Spring WebFlux 实现了响应式编程模型,构建了高吞吐量、高并发的 Web 应用程序,同时也具有响应快速、可扩展性好、资源利用率高等优点。

下面我们来看下 webFlux 是如何将 Servlet 请求异步化的:

1)ServletHttpHandlerAdapter 展示了使用 Servlet 异步支持和 Servlet 3.1非阻塞I/O,将 HttpHandler 适配为 HttpServlet。

2)第10行:request.startAsync()开启异步模式,然后将原始 request 和 response 封装成 ServletServerHttpRequest 和 ServletServerHttpResponse。

3)第36行:httpHandler.handle(httpRequest, httpResponse) 返回一个 Mono 对象(即Publisher),对 Request 和 Response 的所有具体处理都在 Mono 对象中定义。

所有的操作只有在 subscribe 订阅的那一刻才开始进行,HandlerResultSubscriber 是 Reactive Streams 规范中标准的 subscriber,在它的 onComplete 事件触发时,会结束 servlet 的异步模式。

对 Servlet 返回结果的异步写入,以 DispatcherHandler 为例说明:

1)第2行:exchange 是对 ServletServerHttpRequest 和 ServletServerHttpResponse 的封装。

2)第10-15行:在系统预加载的 handlerMappings 中根据 exchange 找到对应的 handler,然后利用 handler 处理 exchange 执行相关业务逻辑,最终结果由 result 将 ServletServerHttpResponse 写入到输出流中。

最后:除了 Servlet 的异步化,作为业务网关,要实现全链路异步化还需要在远程调用方面要支持异步化。在 RPC 调用方式下,我们采用的异步 Dubbo,在 HTTP 调用方式下,我们采用的是 WebClient。

WebClient 默认使用的是 Netty 的 IO 线程进行发送请求,调用线程通过订阅一些事件例如:doOnRequest、doOnResponse 等进行回调处理。异步化的客户端,避免了业务线程池的阻塞,提高了系统的吞吐量。

在使用 WebClient 这种异步 http 客户端的时候,我们也遇到了一些问题:

1)首先:为了避免默认的 NettyIO 线程池可能会执行比较耗时的 IO 操作导致 Channel 阻塞,建议替换成其他线程池,替换方法是 Mono.publishOn(reactor.core.scheduler.Schedulers.newParallel("biz_scheduler", 300))。

2)其次:因为线程发生了切换,无法兼容 Qtracer (Qunar内部的分布式全链路跟踪系统),所以在初始化 WebClient 客户端的时候,需要在 filter 里插入对 Request 的修改,记录前一个线程保存的 Qtracer 的上下文。WebClient.Builder wcb = WebClient.builder().filter(new QTraceRequestFilter())。

8、解决方案Part2:服务编排降低响应时间

Spring WebFlux 并不是银弹,它并不能保证一定能降低接口响应时间,除了全流程异步化,我们还利用 Spring WebFlux 提供的响应式编程模型,对业务流程进行服务编排,降低依赖之间的阻塞。

8.1服务编排解决方案

在介绍服务编排之前,我们先来了解一下 Spring WebFlux 提供的响应式编程模型 Reactor。

它有最重要的两个响应式类 Flux 和 Mono:

  • 1)一个 Flux 对象表明一个包含0..N 个元素的响应式序列;
  • 2)一个 Mono 对象表明一个包含零或者一个(0..1)元素的结果。

不管是 Flux 还是 Mono,它的处理过程分三步:

  • 1)首先声明整个执行过程(operator);
  • 2)然后连通主过程,触发执行;
  • 3)最后执行主过程,触发并执行子过程、生成结果。

每个执行过程连通输入流和输出流,子过程之间可以是并行的,也可以是串行的这个取决于实际的业务逻辑。我们的服务编排就是完成输入和输出流的编排,即在第一步声明执行过程(包括子过程),第二步和第三步完全交给 Reactor。

下面是我们服务编排的总体设计:

如上图所示:

1)service:是最小的业务编排单元,对 invoker 和 handler 进行了封装,并将结果写回到上下文中。主流程中,一般是由多个 service 进行并行/串行地编排。

2)Invoker:是对第三方的异步非阻塞调用,对返回结果作 format,不包含业务逻辑。相当于子过程,一个 service 内部根据实际业务场景可以编排0个或多个 Invoker。

3)handler:纯内存计算,封装共用和内聚的业务逻辑。在实际的业务开发过程中,对上下文中的任一变量,只有一个 handler 有写权限,避免了修改扩散问题。也相当于子过程,根据实际需要编排进 service 中。

4)上下文:为每个接口都设计了独立的请求/处理/响应上下文,方便监控定位每个模块的处理正确性。

上下文设计举例:

在复杂的 service 中我们会根据实际业务需求组装 invoker 和 handler,例如:日历房售卖信息展示 service 组装了酒店报价、辅营权益等第三方调用 invoker,优惠明细计算、过滤报价规则等共用的逻辑处理 handler。

在实际优化过程中我们抽象了100多个 service,180多个 invoker,120多个 handler。他们都是小而独立的类,一般都不会超过200行,减轻了开发同学尤其是新同学对代码的认知负担。边界清晰,逻辑内聚,代码的不可知问题也得到了解决。

每个 service 都是由一个或多个 Invoker、handler 组装编排的业务单元,内部处理都是全异步并行处理的。

如下图所示:ListPreAsyncReqService 中编排了多个 invoker,在基类 MonoGroupInvokeService 中,会通过 Mono.zip(list, s -> this.getClass() + " succ")将多个流合并成为一个流输出。

在 controller 层就负责处理一件事,即对 service 进行编排(如下图所示)。

我们利用 flatMap 方法可以方便地将多个 service 按照业务逻辑要求,进行多次地并行/串行编排。

1)并行编排示例:第12、14行是两个并行处理的输入流 afterAdapterValidMono、preRankSecMono ,二者并行执行各自 service 的处理。

2)并行处理后的流合并:第16行,搜索结果流 rankMono 和不依赖搜索的其他结果流preRankAsyncMono,使用 Mono.zip 操作将两者合并为一个输出流 afterRankMergeMono。

3)串行编排举例:第16、20、22行,afterRankMergeMono 结果流作为输入流执行 service14 后转换成 resultAdaptMono,又串行执行 service15 后,输出流 cacheResolveMono。

以上是酒店业务网关的整体服务编排设计。

8.2编排示例

下面来介绍一下,我们是如何进行流程编排,发挥网关优势,在系统内和系统间达到响应时间全局最优的。

8.2.1)系统内:

上图示例中的左侧方案总耗时是300ms。

这300ms 来自最长路径 Service1的200ms 加上 Service3 的100ms:

  • 1)Service1 包含2个并行 invoker 分别耗时100ms、200ms,最长路径200ms;
  • 2)Service3 包含2个并行invoker 分别耗时50ms、100ms,最长路径100ms。

而右图是将 Service1 的200ms 的 invoker 迁移至与 Service1 并行的 Service0 里。

此时,整个处理的最长路径就变成了200ms:

  • 1)Service0 的最长路径是200ms;
  • 2)Service1+service3 的最长路径是100ms+100ms=200ms。

通过系统内 invoker 的最优编排,整体接口的响应时间就会从300ms 降低到200ms。

8.2.2)系统间:

举例来说:优化前业务网关会并行调用 UGC 点评(接口耗时100ms)和 HCS 住客秀(接口耗时50ms)两个接口,在 UGC 点评系统内部还会串行重复调用 HCS 住客秀接口(接口耗时50ms)。

发挥业务网关优势,UGC 无需再串行调用 HCS 接口,所需业务聚合处理(这里的业务聚合处理是纯内存操作,耗时可以忽略)移至业务网关中操作,这样 UGC 接口的耗时就会降下来。对全局来说,整体接口的耗时就会从原来的100ms 降为50ms。

还有一种情况:假设业务网关是串行调用 UGC 点评接口和 HCS 住客秀接口的话,那么也可以在业务网关调用 HCS 住客秀接口后,将结果通过入参在调用 UGC 点评接口的时候传递过去,也可以省去 UGC 点评调用 HCS 住客秀接口的耗时。

基于对整个酒店主流程业务调用链路充分且清晰的了解基础之上,我们才能找到系统间的最优解决方案。

9、优化后的效果

9.1页面打开速度明显加快

优化后最直接的效果就是在用户体感上,页面的打开速度明显加快了。

以详情页为例:

 

9.2接口响应时间下降50%

列表、详情、订单等主流程各个核心接口的P50响应时间都有明显的降幅,平均下降了50%。

以详情页的 A、B 两个接口为例,A接口在优化前的 P50 为366ms:

A 接口优化后的 P50 为36ms:

B 接口的 P50 响应时间,从660ms 降到了410ms:

9.3单机吞吐量性能上限提升100%,资源成本下降一半

单机可支持 QPS 上限从100提升至200,吞吐量性能上限提升100%,平稳应对七节两月等常规流量高峰。

在考试、演出、临时政策变化、竞对故障等异常突发事件情况下,会产生瞬时的流量尖峰。在某次实战的情况下,瞬时流量高峰达到过二十万 QPS 以上,酒店业务网关系统经受住了考验,能够轻松应对。

单机性能的提升,我们的机器资源成本也下降了一半。

9.4圈复杂度降低38%,研发效率提升30%

具体就是:

  • 1)优化后酒店业务网关的有效代码行数减少了6万行;
  • 2)代码圈复杂度从19518减少至12084,降低了38%;
  • 3)网关优化后,业务模块更加内聚、边界清晰,日常需求的开发、联调时间均有明显减少,研发效率也提升了30%。

10、本文小结与下一步规划

1)通过采用 Spring WebFlux 架构和系统内/系统间的服务编排,本次酒店业务网关的优化取得了不错的效果,单机吞吐量提升了100%,整体接口的响应时间下降了50%,为同类型业务网关提供一套行之有效的优化方案。

2)在此基础上,为了保持优化后的效果,我们除了建立监控日常做好预警外,还开发了接口响应时长变化的归因工具,自动分析变化的原因,可以高效排查问题作好持续优化。

3)当前我们在服务编排的时候,只能根据上游接口在稳定期的响应时间,来做到最优编排。当某些上游接口响应时间存在波动较大的情况时,目前的编排功能还无法做到动态自动最优,这部分是我们未来需要优化的方向。

11、相关文章

[1] 从C10K到C10M高性能网络应用的理论探索

[2] 一文读懂高性能网络编程中的I/O模型

[3] 一文读懂高性能网络编程中的线程模型

[4] 以网游服务端的网络接入层设计为例,理解实时通信的技术挑战

[5] 手淘亿级移动端接入层网关的技术演进之路

[6] 喜马拉雅自研亿级API网关技术实践

[7] B站基于微服务的API网关从0到1的演进之路

[8] 深入操作系统,彻底理解I/O多路复用

[9] 深入操作系统,彻底理解同步与异步

[10] 通俗易懂,高性能服务器到底是如何实现的

[11] 百度统一socket长连接组件从0到1的技术实践

[12] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

[13] 百度基于金融场景构建高实时、高可用的分布式数据传输系统的技术实践


(本文已同步发布于:http://www.52im.net/thread-4618-1-1.html

posted @ 2024-02-21 10:20 Jack Jiang 阅读(37) | 评论 (0)编辑 收藏

本文由得物技术暖树分享,有修订和改动。

1、引言

本文分享的是得物针对现有的消息推送系统的消息送达耗时、实时性、稳定性等方面问题,从零到一构建完整的消息推送质量监控体系和机制的技术实践。

 
 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4614-1-1.html

2、消息推送的作用

2.1 什么是消息推送

消息推送每天都在我们的手机上发生,如下图所示,除非你的手机没有安装App或关闭了通知栏权限。

2.2 消息推送的价值

从用户的生命周期来看,消息推送对于提高App活跃度、提升用户粘性和用户留存率都起到了重要作用。

比如:

  • 1)提升新用户次日留存,低成本促活,对平台的短期留存率影响显著;
  • 2)提升老用户活跃度,push可以通过外部提醒起到拉活的作用;
  • 3)流失用户召回,当用户流失后,若push权限未关闭,通过消息推送的方式,有可能重新唤醒用户。

对于第 2)点,很多内容平台类App的用户push首次启动占比可达 10%以上,因此push对DAU的增量贡献不容小觑。

3、业务背景和技术痛点

消息中心为得物App提供了强大,高效的用户触达渠道。其中push对于得物DAU的贡献有可观的占比,这也就意味着每一条推送消息都是一次与用户沟通的宝贵机会。所以推送的稳定性成为我们关注的首要问题。

那么我们遇到的以下痛点就亟待解决:

1)消息中心没有明确消息推送的耗时标准,业务和技术之间存在gap,业务方对于推送的消息什么时候到达没有明确的心理预期。

2)从技术上来讲消息推送各个节点的耗时不明确,无法对各个节点的耗时做针对性的优化,这也就需要我们针对消息推送的节点耗时进行监控。

3)消息推送的稳定性依赖于第三方的推送通道,而三方通道对于我们来讲就是个黑盒子,如何做到三方通道异常及时发现并止损也是需要考虑的问题。

4)在我们正常的迭代过程中有时候不可避免的会出现些异常或者有坏味道的代码,这些问题能不能及时发现、及时止损,能不能及时告警出来。

4、稳定性监控体系

SLA(Service-Level Agreement),也就是服务等级协议,指的是系统服务提供者(Provider)对客户(Customer)的一个服务承诺。这是衡量一个大型分布式系统是否“健康”的常见方法。

在开发设计系统服务的时候,无论面对的客户是公司外部的个人、商业用户,还是公司内的不同业务部门,我们都应该对自己所设计的系统服务有一个定义好的SLA。因为SLA是一种服务承诺,所以指标可以多种多样。

最常见的四个SLA指标:

  • 1)可用性;
  • 2)准确性;
  • 3)系统容量;
  • 4)延迟。

 

对于消息推送而言,我们主要关注的是消息能否及时可靠的送达给用户,也就是SLA中关注的时效性和稳定性的问题。

目前消息中心针对实效性和稳定性的开发已经完成并初显成效。

系统架构图:

下面主要针对时效性和稳定性的监控做一些介绍。

5、时效性监控的技术实现

5.1 节点的拆分

如何做到时效性的无死角监控,那么我们就要对消息推送的整个流程进行拆分,把整个流程拆分成若干个独立且无依赖的可监控节点。

从消息系统流转图中可以看到:整个推送流程是清晰明了的,消息的的推送主要会经历推送鉴权、用户查询、防疲劳过滤、防重复过滤等的逻辑处理,考虑到每个业务逻辑的处理是相互独立且无依赖的,那我们就可以根据具体的业务处理逻辑进行节点的拆分,这样就可以做到拆分无遗漏,监控无死角。

拆分后的具体节点如下:

5.2 节点耗时的计算

具体的节点拆分逻辑和耗时逻辑的计算如下图:

 

节点耗时的计算:记录节点消息推送到达的时间,并计算节点推送耗时,例如:防疲劳耗时 = T7(antiFatigueConsumeTime) - T6(checkrepeatConsumeTime)。

节点阻塞量的计算:记录节点消息推送的瞬时阻塞量, 例如:防疲劳节点阻塞量 = 防疲劳的总量 - 防疲劳已经处理的量。

5.3 节点指标的制定

既然需要监控的节点已经拆分明确了,那针对这些节点我们监控哪些指标才是有意义的呢。

1)目前消息推送高峰耗时较长,各业务域对于消息的到达时间也没有明确的心理一个预期,另外消息中心也无法感知推送在整个链路各个节点的耗时情况,无法针对节点耗时做到有针对性的优化,所以节点的推送量和推送耗时就是我们需要重点关注的指标。

2)节点的阻塞量可以让我们及时感知到推送中存在的积压问题,在大促期间,消息的推送量也会达到一个高峰,消息目前是否有堆积,处理的速度是否跟的上,是否需要临时扩容,那么节点的阻塞量就成了一个比较有意义的参考指标。

考虑到消息推送是有优先级的并且区分单推和批量推,所以我们要针对不同的优先级和推送方式设置不同的标准。

消息推送耗时的具体标准如下:

5.4 技术方案的实现

为了能感知到消息推送中发生的异常和耗时情况,这就需要我们标准化监控指标和监控的节点。

其中耗时指标可以感知节点的耗时和代码的坏味道,阻塞量可以监控到节点的堆积情况,推送成功率可以感知节点的推送异常等。

另外节点拆分后我们可以很快定位到异常发生的具体位置,经过拆分监控的主要节点包括鉴权、风控、用户查询、防疲劳、防重复、厂商调用等。

另外消息中心每天推送大量消息给得物用户,SLA监控任何一个操作嵌入主流程中都可能导致消息推送的延迟。这也就要求监控和主流程进行隔离,主流程的归主流程,SLA 的归 SLA,SLA 监控代码从主流程逻辑中剥离出来,彻底避免SLA代码对主流程代码的污染,这也就要求SLA逻辑计算需要独立于推送业务的主流程进行异步计算,防止SLA监控拖垮整个主流程,那么Spring AOP+Spring Event就是最好的实现方式 。

5.5 成果

消息推送实效性监控做完之后,对服务节点耗时异常可以及时感知,同时也完成了关键节点耗时的指标化。

可以明确的看到所有节点在各个时间的耗时情况,同时也对消息推送针对各个节点的的优化起到了指导作用。

时效性节点监控:

时效性节点告警:

6、厂商推送监控的技术实现

6.1 监控指标制定

消息推送接入的有多个推送通道,如何做到对这些通道做到无死角的监控,及时感知呢。

1)在做厂商监控之前,我们就已经遇到了厂商通道推送跌零的情况,这种情况下整个推送通道都挂掉了,我们要及时通知厂商进行修复,所以厂商推送跌零告警和厂商余量监控是必须的。

2)从现有数据来看,厂商的推送成功率、回执成功率、点击率都稳定在一定的的区间。如果厂商推送的指标数据偏离这个区间则说明推送有异常,所以推送成功率、回执成功率、点击率的监控是必须的。

3)另外从业务请求发送的用户数来看,每天的消息推送基本是稳定的,相对应的厂商的回执数量和点击数量也是稳定的,那么对厂商推送成功的数量,回执的数量和点击的数量监控也有一定的参考意义。

业务侧请求发送的用户数:

厂商监控告警:

6.2 技术方案实现

厂商每天有数亿的消息推送,这也就意味着厂商的监控不能嵌在主流程中处理。厂商的监控代码要从主流程逻辑中剥离出来,避免监控拖垮主流程,同样避免监控异常影响到推送的主流程。

针对厂商推送的监控,目前使用的是有界内存队列实现:

6.3 成果

消息推送厂商监控上线之后,可以及时感知到厂商推送的异常信息,对于厂商推送的异常和厂商规则的更改等可以做到及时的感知。

 

7、 稳定性监控体系带来的收益

7.1 异常的及时发现

监控上线后及时发现了发现了厂商推送线程关闭失败,厂商推送跌零、厂商营销消息规则更改、厂商通道偶发不可用等问题,并做到了及时的止损。

1)在时效性监控上线之后,发现了因厂商推送线程创建关闭失败导致线程数逐渐上升问题,避免了线上故障的发生。

2)厂商异常导致推送跌零,监控发现后及时通知到厂商并止损。

3)发现厂商营销消息规则更改的异常,并及时经梳理各大厂商文档后发现除了多个厂商通道在未来一个月内也会有规则的更改,消息平台及时适应了厂商规则,接入厂商系统通道,做到了及时止损。

7.2 服务性能的提升

时效性监控上线后发现了多个服务可以优化的点,其中多个厂商和推送节点在高峰推送时耗时较高,很明显节点耗时和厂商推送 SDK 连接池和连接时间参数需要优化。优化后消息推送整体的吞吐量实现了翻倍的提升。

8、 展望未来

由于时间问题,目前消息监控只做了时效性和厂商推送稳定性相关的监控,但是监控上线后带来的收益还是比较可观的,可以预见的是监控的构建在未来必将带给我们更大的收益,后续我们可以从以下点丰富现有监控。

1)考虑到业务预的推送量和推送时间是稳定的,那么我们可以针对业务维度添加推送数据的监控,及时感知上游推送数据的变化。

2)其次我们可以针对各个节点的推送异常、漏斗转化率、服务性能等做监控,进一步丰富消息平台的监控体系。

3)对于消息推送来讲也要考虑推送的转化率问题,那么卸载、屏蔽等指标也是我们需要监控的点,通过这些业务指标及时感知推送的效果,做到精细化的管控。

9、本文小结

消息平台监控上线后带来的收益还是比较可观的,包括多次异常的及时发现和止损,还有发现多个个可以优化的性能点,实现了服务高峰吞吐量的翻倍。

同时也解决了我们现在遇到的以下痛点:

1)时效性明确的给到了不同优先级的耗时标准,避免了业务和技术之间的gap,业务方对于推送的耗时也有了明确的心理预期。

2)时效性使得节点耗时的性能问题可以一目了然,通过对现有节点耗时问题的优化,消息服务的吞吐量实现了翻倍的提升。

3)厂商稳定性监控使得厂商异常可以及时感知,其中厂商稳定性监控上线后发现多起厂商推送的异常,并做到了及时的解决和止损。

4)SLA时效性和厂商稳定性上线后,消息中心可以及时感觉到推送链路的异常和代码的坏味道,特别是对于新上线的代码,如果存在异常可以及时感知。

10、相关文章

[1] 极光推送系统大规模高并发架构的技术实践分享

[2] 魅族2500万长连接的实时消息推送架构的技术实践分享

[3] 专访魅族架构师:海量长连接的实时消息推送系统的心得体会

[4] 实践分享:如何构建一套高可用的移动端消息推送系统?

[5] Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)

[6] 腾讯信鸽技术分享:百亿级实时消息推送的实战经验

[7] 百万在线的美拍直播弹幕系统的实时推送技术实践之路

[8] 京东京麦商家开放平台的消息推送架构演进之路

[9] 技术干货:从零开始,教你设计一个百万级的消息推送系统

[10] 长连接网关技术专题(四):爱奇艺WebSocket实时推送网关技术实践

[11] 喜马拉雅亿级用户量的离线消息推送系统架构设计实践

[12] 直播系统聊天技术(三):微信直播聊天室单房间1500万在线的消息架构演进之路

[13] 消息推送技术干货:美团实时消息推送服务的技术演进之路

[14] 揭秘vivo百亿级厂商消息推送平台的高可用技术实践

11、 得物分享的其它文章

IM跨平台技术学习(七):得物基于Electron开发客服IM桌面端的技术实践

得物从0到1自研客服IM系统的技术实践之路

得物自研客服IM中收发聊天消息背后的技术逻辑和思考实现

(本文已同步发布于:http://www.52im.net/thread-4614-1-1.html

posted @ 2024-01-25 11:27 Jack Jiang 阅读(66) | 评论 (0)编辑 收藏

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅支持UDP 、TCP 、WebSocket 三种协议,支持iOS、Android、H5、小程序、Uniapp、标准Java平台,服务端基于Netty编写。

工程开源地址是:

关于RainbowChat

► 详细产品介绍:http://www.52im.net/thread-19-1-1.html
► 版本更新记录:http://www.52im.net/thread-1217-1-1.html
► 全部运行截图:Android端iOS端
► 在线体验下载:专业版(TCP协议)专业版(UDP协议)      (关于 iOS 端,请:点此查看

 

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题(可自行下载体验:专业版下载安装)。

* RainbowChat可能是市面上提供im即时通讯聊天源码的,唯一一款同时支持TCP、UDP两种通信协议的IM产品(通信层基于开源IM聊天框架  MobileIMSDK 实现)。

v11.0 版更新内容

此版更新内容更多历史更新日志):

(1)Android端主要更新内容新增“@”功能、消息引用功能等】:

  • 1)[新增] 新增“@”功能;
  • 2)[新增] 新增消息引用功能(支持引用全部消息类型);
  • 3)[bug] 解决了转发的是收到的短视频消息时,发送者这边不从网络加载预览图的问题;
  • 4)[bug] 解决了离线好友消息在首页“消息”列表上显示的时间不是最后一条消息的发送时间问题;
  • 5)[优化] 首页消息列表中的语音消息将显示语音时长(跟新版微信一样);
  • 6)[优化] 其它优化及bug修复。

(2)服务端主要更新内容:

  • 1)[新增] 增加了“@”功能相关数据字段和代码逻辑的实现;
  • 2)[新增] 增加了消息引用功能相关数据字段和代码逻辑的实现;
  • 3)[优化] 更新了消息推送特权接口,支持陌生人、好友、群聊3种消息的推送,且增加了主机ip检查(提高安全性);

此版新增功能运行截图更多截图点此查看):

posted @ 2024-01-24 12:44 Jack Jiang 阅读(41) | 评论 (0)编辑 收藏

本文由百度搜索技术平台研发部分享,本文有修订和改动。

1、引言

分布式数据传输系统是一种用于在多个计算节点之间高效传输大量数据的系统,诣在高效的解决大规模数据迁移、备份、跨地域复制等问题。其广泛应用在实时数据流传输、跨数据中心数据迁移、多媒体传输等场景,在大多数企业中的日志管理、业务数据建库等场景中也都会使用到。

众所周知,数据的高效传输往往直接影响着企业对市场先机的把握,对企业发展有重要意义,特别是在金融领域,如证券行业,它对分布式数据传输系统的设计提出了更高的要求,证券领域数据变化飞快,一个高时效、稳定的数据流传输系统不仅能有效的提升用户体验,更能提供用户一手的投资信息,有助于用户的投资决策,进而拉进企业与用户的距离。

本文将通过一个百度搜索旗下的金融场景案例来分享构建高实时、高可用的分布式数据传输系统的技术实践。

 
 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4602-1-1.html

2、业务背景

作为百度搜索场景下时效性要求较高的业务,金融承载着每天数千万次的用户搜索请求。

而在2021年以前,金融业务的数据一直都是采用传统的互联网引入方式,该方式的特点是接入成本较低,但受公网等不可控因素影响,数据时效性较差,且数据断流、错误等问题频出,随即而来的就是业务维护成本较高,十分不利于产品迭代。

我们基于此发起了一个证券数据直连项目,诣在通过接驳全球各大证券交易所数据中心来构建一个高时效、高可用的分布式传输系统,从而有效的解决传统数据引入方式(公网抓取、推送)所带来的时效性、稳定性、正确性等问题,进而满足全国乃至全球用户的金融需求。

3、设计目标

3.1业务目标

接驳全球各大证券交易所Level-1行情数据,来覆盖全量上市公司股票、外汇、期货、ETF、涡轮牛熊等证券业务来满足用户需求,时效性追平金融行业竞品,为打造强大的金融生态做数据基建储备。

Level-1行情简称LV1行情:是交易所根据交易规则发布的即时行情信息,数据格式包括基于FIX/FAST协议的接口和TXT文件、二进制数据流等,行情通过交易所信息技术公司的高速地面网和宽带广播卫星系统发布或上证所信息网络有限公司的互联网和专线传输。

3.2技术目标

1)基础设施建设:协同交易所、运营商完成物理专线的链路部署,通过物理专线接入的方式在百度云机房接入上海、深圳、香港、纳斯达克证券交易所数据中心,适配交易所单、组播协议将二进制流/文本数据引入到百度内部,再分别完成华南、华北、华东、香港(支持海外访问)地域的数据存储与转发,同时支持负载和流量调度来支撑各地域的用户请求。(注:这里的物理专线特指光缆)

2)时效性和稳定性提升:行情数据检索99分位耗时不超过200ms,数据稳定性从99%提升至99.99%以上,数据灾备能力从1主0备升级至1主2备。

3)数据安全:基于百度安全能力,构建类似的防火墙策略来严格控制每一个机房、每一个集群的出入权限,并且配置好相应的安全组策略。

4、关键思路

从功能和网络拓扑上来看,一个高时效、高可用的金融数据传输系统至少需要包含以下几个部分,我们逐个来进行解读。

4.1接入层

适配全球各大交易所单、组播传输协议,确保数据能在专线物理网络正常传输。

接入主要有2种方式:

  • 1)一种是走互联网;
  • 2)一种是走物理专线。

前者相对比较灵活:各类数据协议基本都可以支持,有直接走HTTP(GET/POST),或者是走消息队列的发布订阅等等,接入成本较低,属立即接入那种,但受公网的不可控因素影响,在传输效率和安全性上相对后者会有比较大的差距,我们一般会把互联网的方式当做一个灾备能力存在。

专线方式的特点:是仅点对点传输,由于用的是独立的光缆,在有限带宽内理论可以做到无争用状态,不受公网影响,属可靠传输,传输协议私有化,增加了更多的认证机制。因此也更安全,区分不同应用场景,像证券类数据传输,一般交易所采用的是单播、组播方式,当下用的多的是组播。另外专线中也有主备的概念,一般会预留1-2条线路做灾备,整体下来,专线的费用要更昂贵一些,接入的周期也更长,往往长达几个月。

4.2网络层

完成华南、华北、华东百度云机房虚拟网络架构建设,包括子网、路由、网关等。

虚拟网络的核心组成部分主要是子网、路由、网关、虚拟机,其中每个子网关联着一个虚拟机集群,我们把整个组成部分(域)统称为一个VPC(Virtual private Cloud),路由又区分为TGW路由和对等连接。

这里主要关注对等连接,它是为用户提供了VPC级别的网络互联服务,使用户实现在不同虚拟网络之间的流量互通,实现同区域/跨区域,同用户/不同用户之间稳定高速的虚拟网络互联,其核心是基于对路由表的操作,对等连接也支持配置地域级的DNS同步。

网关又分为NAT网关和专线网关:

1)一个对外:比如设置SNAT和DNAT规则用于统一网段的外网出口;

2)一个对内:对内其实就是确保能够走专线和内部网络打通。

4.3传输层

完成各机房内的数据解析、存储、同步、转发等。

对于接入层获取到的数据我们分为三个级别:

1)像交易所主要是二进制流、文本为一级数据,我们需要保留近一段时间的原始数据落在本地(一级数据管理集群),以便用作应急回放。

2)而解码后的数据为二级数据,落在二级数据管理集群上,主要用于跨地域同步。

3)最后,对解码后的数据进行计算&加工,作为三级数据,落在三级数据管理集群用于承接应用服务。同时,按协议解码后的数据按照使用场景区分为实时流(如分时)、延时流(如K线),延时流经过实时流计算得来,实时流同步进内存用于提升IO效率,延迟流通过实时流的计算后异步进DB,DB维护在三级数据管理集群上。

4.4应用层

负载/流量调度、监控能力等建设。

应用层的设计,主要有两个方面的考虑:

1)一方面是对于接入层的负载和流量调度,如通过部署websocket/http服务来支撑百度用户流量,使用BLB(Baidu Load Balance)将同一区域的多台百度智能云服务器虚拟成一个组,设置一个内网或外网的服务地址,将前端并发访问转发给后台多台云服务器(BCC),实现应用程序的流量均衡,性能上实现业务水平扩展。

负载均衡还通过故障自动切换及时地消除服务的单点故障,提升服务的可用性,支持服务器调度权重策略配置,并支持TCP、HTTP等协议。

2)一方面是对监控的应用,如请求/数据传输日志落盘、统计、分析以及流量和sla监控等。

4.5小结

将以上四层能力建设后,此时单机房内的网络拓扑应该如下图所示。

注:DCC/BBC/BCC都是百度云范畴的机器类型,更多细节可以参考百度智能云私有网络:https://cloud.baidu.com/doc/VPC/s/Vjwvytu2v

5、核心难点1

公网和私有网络方式下如何在云上完成多协议适配,尤其是在私有网络中适配单播、组播协议以及如何做组播转单播。

5.1公网&私有网络接入介绍

对于一个数据传输系统来说,最重要的一点其实就是能支持多协议的数据适配来提升系统的灵活性,证券交易所一般提供的接入方式有公网接入和私有网络接入,公网接入的成本较低,一般周粒度就可完成,没有复杂协议约束。

而私有网络往往会有更高的要求,协议上大部分都要求具备单播介入能力,少部分像纳斯达克和深圳交易所会要求下游支持组播接入。绝大多数的云厂商是无法直接在虚拟机上适配的,传统券商基本都是完全使用昂贵的物理机资源来承载,虽然物理机插拔更方便也更稳定,但运维管理成本也更高。

两种方式在效果和成本上也有本质的区别:

1)公网接入:公网比较常见的数据接入方式主要是HTTP/HTTPS方式,当然也会有RPC/FTP,只是用的相对少一些。

为了提升数据传输安全,双方可以在调用前协商好数据加密算法和密钥。优点是接入成本较低,能快速应用,尤其在跨洋传输上会有体现。缺点是走的公共线路,网络不可靠,且数据易被截获,当攻击者捕获两端的数据包后,哪怕不能完全解析,也可以实施一些流量攻击手段以影响服务稳定性。总的来说,一般不会对于安全性、时效性要求较高的数据采用该方式接入,更多是只是一种备用方式(特殊场景除外,如跨洋传输)。

2)私有网络接入:公司内网其实就属于一个私有网络,但是对于跨公司传输数据的场景,要想构建私有网络,一般会走物理专线接入的方式。

这种点对点传输方式的显著优点是专网专用且安全性较高,基本不受公共网络影响(自然灾害等不可抗力除外),在带宽范围内基本可以做到无网络争用状态(数据即发即达),由于是私有网络(双端内网传输),基本不用担心数据安全问题,而且往往还会增加额外的数据校验手段,尤其在金融场景,会有严格的token(硬/软)认证,该方式的缺点是成本相比公网传输接入成本更高,一般要持续数月,费用更昂贵,一般在上百万元,依赖选取的传输介质(一般选择光纤)和带宽。

5.2私有网络中单播、组播协议接入方案

私有网络有单播、广播、组播之分。

1)单播:相对比较好适配一些,走静态路由的方式在同一个VLANID下分别配置云端和IDC端的IP段作为IPV4专线互联地址即可。

2)广播:一般是对于服务端而言,比如证券交易所下游对接着全球范围的所有券商,数据源是相同的,一般会采用广播的机制把数据推送给所有下游。

3)组播:一般是要求下游需要适配,现如今大部分业务都已经上公有云,在云上常用虚拟化技术来完成服务器集群的部署。

对于虚拟机来说,更多的支持单播传输,不支持组播传输,往往需要在专门的物理设备(组播路由器、或特定的组播软件)上配置转发组播报文的路由,路由表关联着具体的路由协议(如PIM),再用IGMPV3协议来完成组播成员和报文的管理,通过动态BGP维护邻居关系(现在的云厂商上对BGP的可能是固定分配AS号,如果有AS的要求还是需要在物理机上单独做),我们可以圈出一部分物理资源专门承载组播数据传输,通过配置IGMP Snooping(可以将组播报文转发到二层数据链路层,实现组转单,注意版本需要是3,否则无法转发IGMPV3报文)+ AP完成组播转单播配置,再通过双网卡(WAN口+LAN口)形式实现专线网络数据接入&同步到百度内网,物理机通过三层交换机来关联,构造出类似下面的网络拓扑(如下图所示)。

6、核心难点2

6.1概述

数据管理&跨地域同步,数据灾备能力、时效性提升。

数据的分层管理主要是应对单机房内的场景,而对于跨机房或者说跨地域的主要难点是数据同步,后者需要更多的考虑跨机房数据传输效率和灾备管理,核心是网络设计。

6.2数据管理

按使用场景的不同,将数据分交易所二进制流数据(原始数据流)、文本数据、业务数据/日志等。

1)原始数据流:主要应对单机房、跨机房传输场景,当出现下游业务服务异常导致的数据展现错误时,存储的原始数据流可以很好的对数据进行回放,以便快速恢复业务,尤其是应对金融证券数据传输场景,证券交易所一般不会推送重复数据,如果下游业务服务异常导致存储的业务数据全部失效或为脏数据,那可能只能通过refresh主动请求上游来重新获取。

但这样做可能会出现核心数据丢失,由于这种方式的效率较低,还会扩大业务受损的影响面,因此一般会先存储交易所下发的原始数据流,业务可以自定义存储方式和周期,当出现问题时,可以通过『重播』原始数据流来止损。

另外原始数据流还能用于在对等网络中的跨机房恢复业务数据。

2)业务数据流:主要应对单机房传输的场景,根据模块分工的不同,分证券的实时行情、历史行情等等,对于单机房数据集群的管理我们有很多方式,对于自研的DB,在调度上可以用一些标准的分布式管理手段(如zk),数据同步的手段一般需要自定义,对于传统的DB如Mysql、Redis、Mongo等,一般有标准化的数据同步方式和调度模式。

6.3跨地域同步

跨机房地域同步的前提是多个机房之间需要有直接或间接关联关系的专用物理网络,即确保网络是可达的,然后再结合虚拟网络完成子网及路由配置。

对于具有直接网络关联关系的2个机房来说,我们的对等网络(Peer Connection)设计稍微简单一些。

现在各个云厂商也基本都支持直接配置了,其原理是首先在同一个VPC下划分好子网并规划好集群规模,其次通过配置路由表的方式完成本端和对端的下一跳关联,这样就完成了2个直接对端的对等网络建设。

接着再配置和内网专线的路由,就能做到云机房->内网机房的网络互通。

但如果2个机房没有直接关联关系,而又需要完成本端和对端数据同步怎么办呢,比如有A B C三个机房,只有A-B B-C有直接关联关系,而我们想要让A-C关联,这时候不可能说再建立一条物理链路,我们可以采用类似桥接的方式(或者叫隧道),同时关联A-B-C三个机房,其中B作为一个"网桥",再通过NAT技术完成IP地址转换,确保C可以识别从A过来的路由,而A-B B-C 正常采用对等网络的方式完成基础网络配置,这样就可以胯多个机房进行通信,由于是物理网络传输,机房间的耗时不会有很大差别(30ms内)。

由于网络细节的篇幅较多,我们不做详细的赘述,这里我们看看跨地域同步的网络架构(如下图所示)。

 

注:图中网段可以根据不同场景做划分,这里只做简单介绍。

6.4数据灾备能力、时效性提升

数据灾备:我们一般选择离各个证券交易所就近的一个接入点,比如上证选择在上海机房接入,深证选择在广州接入,纳斯达克在香港接入,每个接入点配置2条专线用做物理链路的主备,同时扩展一条互联网通路(注意这里的互联网也是直接和交易所对接,已经不是传统数据引入渠道)做次备,链路默认都是活跃状态,有专们的物理设备会根据专线的健康状况(自定义逻辑)自动切换。

最后,再根据上面提到的跨地域同步的原理,在云机房关联各条物理链路,在每条物理链路上抽象出独立的VPC,通过构建网络拓扑实现跨机房数据复制及灾备。

时效性:物理专线(光缆)接入方式天然的优势就是数据"即发即达",因为在固定带宽内基本不存在网络争用,而且现在大部分线路都会配置中继,其损耗带来的影响相对可控,因此接入方式就决定了数据传输的时效性。

相比传统互联网接入方式,单从数据上来看,专线接入SLA超过5个9(互联网接入2个9),当然也会配置上重传机制来进一步提升数据到达的可靠性。

交易所下发数据的数据频率按市场划分,A股一般3s/笔,港美股没有特殊限制,即有成交即下发,除去光损耗带来的影响,最快可以到3ms/笔,由于频率越高,对机器要求也越高,为此我们特殊做了一些限频操作,整体的数据时效性基本会在60ms(99.99+分位)内。

7、核心难点3

7.1概述

集群管理&单地域、跨地域流量调度。

流量调度生效在应用层,主要是找到一种高效的调度/负载方式来对内/外的业务提供数据支撑,从协议上/应用场景划分主要有TCP/HTTP,策略上因业务而异,主要还是基于对流量分配中权重的定义。

比如有基于RS健康检查的分配,每隔一段时间探测一下下游集群的健康状况来动态调整流量配比,也可以根据下游机器的连接数来分配,还可以基于对资源访问的热度来分配,区分单地域和跨地域场景如下面所述。

7.2单地域场景

现在各个云厂商都有相应的流量调度产品支撑,比如百度云上有BLB(Baidu Load Balance),可以很轻松构建一个调度规则出来,在BLB下可以设置调度集群的协议(TCP/HTTP),然后关联对应的服务器集群,最后给不同的服务器集群配置权重策略。

当流量进来时,BLB会帮我们完成自动分配,在某一个集群出现问题时,可以手动调整集群权重来干预流量配比,即所谓的切流。

7.3多地域场景

多个机房间的流量调度策略是在云上一般是隔离开的,当然我们可以在多个机房的最上层再抽象出一个专门的调度集群,对外暴露一个VIP。

在这个VIP上配置多个地域之间的调度关系,互联网公司基本上也都是这么做的,更多的是针对超大集群规模的场景,而且VIP的选取也是有条件/成本的。

但如果想低成本快速在云上创建一个能支持多地域同时访问且具备自动化流量调度的应用,且云上又不支持多地域共享VIP的功能时,我们可以尽可能多的基于云上已有的功能自己完成,在每个机房内部单独抽出一个类似nginx的集群,每个集群上维护着不同于本地域的调度关系,它们的下游就是不同于本机房的BLB,同时互相检查对方的健康状况并上报监控系统,这样当出现异常时,除了能针对性的在本机房内完成BLB级的流量调度,还能做到多机房间的流量切换,以提升机房间的灾备能力。当然,也需要有足够的容量。

 

8、总体设计

上图各个模块的作用如下(各模块均采用多路复用):

1)源数据接入集群:适配2种方式(互联网/物理专线)+各类协议(互联网、单播、组播)的数据源接入;

2)源数据转发集群:确保各机房源数据的一致性,降低由于业务服务本身带来的数据不一致问题;

3)数据解析集群:公共模块,主要是针对源数据进行统一的处理,以便转发给下游各业务;

4)业务数据集群(实时/延时流):负责将数据解析集群下发的内容转换成业务详细数据,也就是B端或C端用户看到的数据;

5)网关集群:负责承载用户访问流量;

6)监控集群:负责收集各个集群上报的日志情况,并作为稳定性管理手段之一。

可以看到:机房B相比其他机房,少了接入层配置,这主是基于成本和性能上考虑,把机房B当做数据传输枢纽,不仅能保证本机房数据传输,也能支持跨机房的数据同步&复制。该分布式传输系统从数据接入到监控集群,整体机器规模不大(100左右),但可支撑超过10亿的流量。

9、本文小结

一个良好的产品体验及产品矩阵,其背后一定离不开一个高可用、高时效的数据支撑,尤其是在金融领域,用户只可能会为一手的信息、完善的产品功能买单。

自21年完成数据通路建设以来,金融的稳定性和业务规模都有了质的飞跃,证券数据时效性问题从季度数十个降低到年度1个以内,99分位耗时更是从过去的分钟级降低到60ms以内,数据SLA从2个9左右提升至5个9以上,产品覆盖股票、外汇、基金、期货等诸多领域,也是第一个在搜索领域支持行情长连接的业务,基于搜索生态也孵化出来了像百度股市通PC站、app等多个独立端产品,目前正在结合AI能力进行持续优化,期望从完善用户体验->帮助用户决策进阶,也让金融投资变得更智能,更简单。

本文主要结合一个金融数据接入案例对分布式数据传输系统做了一个简单的介绍,包括传输系统中的一些核心节点的设计,如数据接入层的多协议适配、数据的分层管理以及跨地域的数据同步对应的网络拓扑等,通过实验得出结论,该方案能很好的应用在各种规模的分布式数据传输系统设计中。当然,由于篇幅问题,也省略了很多实现上的细节,读者有任何问题可以留言,可以一起探讨,也会尽量答复。

10、相关文章

[1] 技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解

[2] 以网游服务端的网络接入层设计为例,理解实时通信的技术挑战

[3] 知乎千万级并发的高性能长连接网关技术实践

[4] 手淘亿级移动端接入层网关的技术演进之路

[5] 喜马拉雅自研亿级API网关技术实践

[6] 石墨文档单机50万WebSocket长连接架构实践

[7] 小米小爱单机120万长连接接入层的架构演进

[8] B站基于微服务的API网关从0到1的演进之路

[9] 百度统一socket长连接组件从0到1的技术实践

[10] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

11、其它百度技术分享

百度APP移动端网络深度优化实践分享(一):DNS优化篇

百度APP移动端网络深度优化实践分享(二):网络连接优化篇

百度APP移动端网络深度优化实践分享(三):移动端弱网优化篇

全面了解移动端DNS域名劫持等杂症:原理、根源、HttpDNS解决方案等

深入了解百度开源的分布式RPC框架brpc的方方面面

直播系统聊天技术(四):百度直播的海量用户实时消息系统架构演进实践

IM消息ID技术专题(五):开源分布式ID生成器UidGenerator的技术实现

百度统一socket长连接组件从0到1的技术实践

百度网盘千万节点的P2P架构设计(PPT) [附件下载]

即时通讯音视频开发(二十):一文读懂视频的颜色模型转换和色域转换

揭秘百度IM消息中台的全量用户消息推送技术改造实践

百度基于金融场景构建高实时、高可用的分布式数据传输系统的技术实践


(本文已同步发布于:http://www.52im.net/thread-4602-1-1.html

posted @ 2024-01-18 11:22 Jack Jiang 阅读(43) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第32 期。

[- 1 -] IM开发干货分享:如何优雅的实现大量离线消息的可靠投递

[链接] http://www.52im.net/thread-3069-1-1.html

[摘要] 本文作者将以自已IM开发过程中的真实总结,分享针对大量离线聊天消息,在确保用户端体验不降级的前提下,保证离线消息的可靠投递。


[- 2 -] IM开发干货分享:有赞移动端IM的组件化SDK架构设计实践

[链接] http://www.52im.net/thread-3088-1-1.html

[摘要] 本文主要以Android客户端为例,记录了有赞旗下 App 中使用自研 IM,并将IM提炼成组件化SDK的设计思路。


[- 3 -] 一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等

[链接] http://www.52im.net/thread-3445-1-1.html

[摘要] 本文主要聚焦这套亿级用户的IM架构的一些比较细节但很重要的热门问题上,比如:消息可靠性、消息有序性、数据安全性、移动端弱网问题等。


[- 4 -] IM扫码登录技术专题(一):微信的扫码登录功能技术原理调试分析

[链接] http://www.52im.net/thread-2941-1-1.html

[摘要] 本文将以轻松活泼的语言形式,为你分析和讲解微信手机扫码登录的技术原理,希望在你的IM中开发此功能时有所启发。


[- 5 -] IM扫码登录技术专题(二):市面主流的扫码登录技术原理调试分析

[链接] http://www.52im.net/thread-2892-1-1.html

[摘要] 本文将简要的介绍扫码登录功能的技术实现逻辑,并实际结合淘宝、微信的扫码登录功能,学习和研究大厂主流应用的技术实现思路。


[- 6 -] IM扫码登录技术专题(三):通俗易懂,IM扫码登录功能详细原理一篇就够

[链接] http://www.52im.net/thread-3525-1-1.html

[摘要] 最近刚好看到一个二维码的技术原理讲解视频,正好借此机会将扫码登录的详细技术原理梳理并总结一下,方便自已回顾,也希望能帮助到想在IM里开发类似功能的同行们。


[- 7 -] IM扫码登录技术专题(四):你真的了解二维码吗?刨根问底、一文掌握!

[链接] http://www.52im.net/thread-3735-1-1.html

[摘要] 二维码技术使用起来很简单,本系列的前三篇文章也专门针对IM扫码登录这个功能做了详细的分享,但本着学习技术不留死角的习惯,我认为有必要单独学习一下到底什么是二维码。


[- 8 -] 理解IM消息“可靠性”和“一致性”问题,以及解决方案探讨

[链接] http://www.52im.net/thread-3574-1-1.html

[摘要] 本文内容仅供参考,具体的解决方案请务结合自已的系统构架和实现情况,多阅读几篇即时通讯网上有关这个技术话题的文章,取其精华,找到适合自已的技术方案和思路才是最明智的。


[- 9 -]  阿里技术分享:闲鱼IM基于Flutter的移动端跨端改造实践

[链接] http://www.52im.net/thread-3615-1-1.html

[摘要] 本文总结了阿里闲鱼技术团队使用Flutter在对闲鱼IM进行移动端跨端改造过程中的技术实践等,文中对比了传统Native与现在大热的Flutter跨端方案在一些主要技术实现上的差异,以及针对Flutter技术特点的具体技术实现,值得同样准备使用Flutter开发IM的技术同行们借鉴和参考。


[- 10 -] 融云技术分享:全面揭秘亿级IM消息的可靠投递机制

[链接] http://www.52im.net/thread-3638-1-1.html

[摘要] 本文根据融云亿级IM消息系统的技术实践,总结了分布式IM消息的可靠投递机制,希望能为你的IM开发和知识学习起到抛砖引玉的作用。


[- 11 -] IM全文检索技术专题(三):网易云信Web端IM的聊天消息全文检索技术实践

[链接] http://www.52im.net/thread-3651-1-1.html

[摘要] 本文将具体来聊聊网易云信是如何实现IM客户端全文检索能力的,希望能带给你启发。


[- 12 -]  IM开发干货分享:万字长文,详解IM“消息“列表卡顿优化实践

[链接] http://www.52im.net/thread-3732-1-1.html

[摘要] 本文将要分享是融云IM技术团队基于对自有产品“消息”列表卡顿问题的分析和实践(本文以Andriod端为例),为你展示一款IM在解决类似问题时的分析思路和解决方案,希望能带给你启发。


👉52im社区本周新文:《百度基于金融场景构建高实时、高可用的分布式数据传输系统的技术实践》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2024-01-17 12:01 Jack Jiang 阅读(40) | 评论 (0)编辑 收藏

本文由21CTO万能的大雄分享,本文有修订和改动。

1、引言

在当今快速发展的技术环境中,对跨平台桌面应用程序的需求正在不断激增。

开发人员面临着选择正确框架之挑战,以便可以高效构建可在 Windows、macOS 和 Linux 上无缝运行的应用程序。

在本文中,我们将比较五种流行的桌面应用程序开发框架:ElectronFlutterTauriReact Native  Qt,希望可以帮助你根据项目需求做出明智的技术选型决策。

 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4598-1-1.html

2、系列文章

本文是系列文章中的第10篇,本系列总目录如下:

IM跨平台技术学习(一):快速了解新一代跨平台桌面技术——Electron

IM跨平台技术学习(二):Electron初体验(快速开始、跨进程通信、打包、踩坑等)

IM跨平台技术学习(三):vivo的Electron技术栈选型、全方位实践总结

IM跨平台技术学习(四):蘑菇街基于Electron开发IM客户端的技术实践

IM跨平台技术学习(五):融云基于Electron的IM跨平台SDK改造实践总结

IM跨平台技术学习(六):网易云信基于Electron的IM消息全文检索技术实践

IM跨平台技术学习(七):得物基于Electron开发客服IM桌面端的技术实践

IM跨平台技术学习(八):新QQ桌面版为何选择Electron作为跨端框架

IM跨平台技术学习(九):全面解密新QQ桌面版的Electron内存占用优化

IM跨平台技术学习(十):快速选型跨平台框架Electron、Flutter、Tauri、React Native等》(* 本文)

3、初识框架

1)Electron:

* 技术背景:Electron 由 GitHub 开发,因其使用 HTML、CSS 和 JavaScript 等 Web 技术构建跨平台桌面应用程序的能力而广受欢迎。

* 主要功能:Electron 通过其 Node.js 集成提供对本机 API 的轻松访问,使开发人员能够创建功能丰富的应用程序。它还支持用 C++ 编写的本机插件,尽管构建这些插件可能更复杂且容易出错。

2)Flutter:

* 技术背景:Flutter 由 Google 创建,以其在移动应用程序开发中的使用而闻名,但也可用于桌面应用程序。

* 主要特点:Flutter 提供了一组丰富的可定制 UI 小部件,其 Dart 代码被编译为本机机器代码,从而实现快速执行并减少开销。它采用独特的“基于小部件”架构,提供丰富的可定制 UI 小部件。

3)Tauri:

* 技术背景:Tauri 是一个较新的框架,旨在创建安全且轻量级的桌面应用程序。它旨在弥合 Rust 和 Web 技术之间的差距。

* 主要功能:Tauri 支持使用 Rust 或 C 构建本机插件,从而可以访问 Web 平台中不可用的本机 API 和功能。

4)React Native:

* 技术背景:React Native,同样来自 Facebook,主要以移动应用程序开发而闻名,但也有桌面应用程序开发的扩展。

* 主要功能:React Native 提供了一种访问本机 API 和功能的方法,但与其他框架相比,它可能需要更多的努力。它支持无缝集成第三方库。

5)Qt:

* 技术背景:Qt 是一个 C++ 框架,绑定了多种语言,包括 Python 和 JavaScript。这是一个历史悠久、历史悠久的框架。

* 主要功能:Qt 提供出色的本机集成功能,允许开发人员访问本机 API 和功能。它提供了一套用于构建跨平台桌面应用程序的全面工具,并强调本机外观和感觉。

4、跨平台能力

在跨平台功能方面,Electron、Flutter、Tauri 和 Qt 足以在多个操作系统上运行应用程序。它们为 Windows、macOS 和 Linux 提供广泛的支持,使其成为需要广泛兼容性的项目的合适选择。

React Native 虽然主要是为移动设备设计的,但可以扩展以创建桌面应用程序。然而,它的跨平台支持可能不像其他框架那样无缝,并且可能需要额外的努力才能在所有平台上实现一致的性能和 UI。

5、性能表现

性能是桌面应用程序开发的关键因素。

以下是这些框架的性能特征:

  • 1)Electron:以其较高的资源使用率而闻名,Electron 应用程序可能会占用更多内存和 CPU,从而影响较旧或功能较弱的计算机的性能;
  • 2)Flutter:Flutter 的性能值得称赞,这要归功于它的编译代码和 GPU 加速。它提供快速的启动时间和流畅的动画;
  • 3)Tauri:Tauri 因其轻量级特性和低资源消耗而脱颖而出。它是构建快速且响应灵敏的桌面应用程序的绝佳选择;
  • 4)React Native:React Native 桌面应用程序可以节省资源,但跨平台优化性能可能需要额外的工作;
  • 5)Qt:Qt 的性能非常出色,提供类似本机的速度和响应能力。它是资源密集型应用程序的首选。

6、用户界面

创建丰富且响应迅速的用户界面是桌面应用程序开发的一个重要指标。

以下是这些框架在 UI 功能方面的比较:

  • 1)Electron:Electron 提供了大量预构建的 UI 组件和广泛的主题选项。开发人员可以轻松创建具有视觉吸引力的应用程序;
  • 2)Flutter:Flutter 基于小部件的方法允许高度可定制且具有视觉吸引力的用户界面。它提供了广泛的开箱即用的小部件;
  • 3)Tauri:Tauri 不像其他框架那样提供那么多的 UI 组件,但允许对用户界面进行严格控制,这有利于创建独特的设计;
  • 4)React Native:通过React Native,开发人员可以使用第三方库和组件进行UI设计。可能需要额外的工作才能实现完全定制的外观;
  • 5)Qt:Qt 擅长提供与目标平台无缝集成的类似本机的 UI 元素。它是需要精美原生外观的应用程序的首选。

7、开发经验

流畅的开发工作流程对于生产力至关重要。

以下是这些框架在开发经验方面的比较:

  • 1)Electron:Electron 提供了一套广泛的开发工具和一个活跃的社区。调试和热重载得到良好支持;
  • 2)Flutter:由于其基于 widget 的架构和强大的文档,Flutter 的开发体验得到了简化。热重载是一个突出的功能;
  • 3)Tauri:Tauri 仍然相对较新,但使用 Rust 和 JavaScript 提供了简化的开发过程。它强调快速发展;
  • 4)React Native:React Native 为 Web 和移动开发人员提供了熟悉的开发体验。然而,过渡到桌面可能需要一个学习曲线;
  • 5)Qt:Qt 提供了一个成熟的开发环境,具有广泛的 IDE 和工具。它以其稳定性和全面的文档而闻名。

8、原生集成

访问本机平台功能和 API 对于许多桌面应用程序至关重要。

让我们看看这些框架如何处理本机集成:

  • 1)Electron:Electron 通过 Node.js 集成提供对本机 API 的轻松访问。它还支持用 C++ 编写的本机插件,尽管构建这些插件可能更复杂且容易出错;
  • 2)Flutter:Flutter 的 Dart 代码被编译为本机机器代码,从而实现快速执行并减少开销。它采用了一种称为“基于小部件”架构的独特方法,提供了一组丰富的可定制 UI 小部件;
  • 3)Tauri:Tauri 支持使用 Rust 或 C 构建原生插件,可用于访问 Web 平台中不可用的原生 API 和功能;
  • 4)React Native:React Native 提供了一种访问本机 API 和功能的方法,但与其他框架相比可能需要更多的努力。它支持无缝集成第三方库;
  • 5)Qt:Qt 提供出色的本机集成功能。它是一个 C++ 框架,绑定了多种语言,包括 Python 和 JavaScript,可用于访问本机 API 和功能。

9、社区与生态系统

开发人员社区的规模和活跃度,可以显着影响框架的成功和第三方库的可用性。

这些框架的表现如下:

  • 1)Electron:Electron 拥有一个庞大而活跃的社区,提供大量可用的插件和扩展;
  • 2)Flutter:Flutter 拥有不断增长的社区和越来越多的软件包,主要专注于移动开发,但也有桌面扩展;
  • 3)Tauri:Tauri 仍在成长,但其社区充满热情并致力于其发展。其生态系统正在稳步扩展;
  • 4)React Native:React Native 拥有完善的社区,主要专注于移动开发。桌面扩展社区规模较小,但正在不断增长;
  • 5)Qt:Qt 拥有悠久的历史和强大的生态系统,拥有庞大的工具、小部件和扩展库。

10、 框架们的成功案例

让我们探索一些现实世界的用例和使用这些框架构建的应用程序示例,以更好地了解它们在不同场景中的优点和缺点。

以下是具体的场景举例:

  • 1)Electron:广泛用于构建跨平台桌面应用程序,包括代码编辑器(VSCode)、通信工具(Slack)和娱乐应用程序(Spotify);
  • 2)Flutter:Flutter 逐渐成为富媒体应用程序的选择,已用于 Google Ads、阿里巴巴和 Reflectly 等应用程序;
  • 3)Tauri:Tauri 正在获得轻量级、安全应用程序的青睐,包括密码管理器 (LosePass) 和通信工具 (Mailspring);
  • 4)React Native:虽然主要是一个移动框架,但 React Native 已扩展到 Discord 和 Microsoft Teams 等应用程序中的桌面使用;
  • 5)Qt:Qt 是一种多功能选择,可用于从工业软件到游戏和汽车信息娱乐系统的广泛应用。

11、开发时的挑战

虽然每个框架都有其优点,但必须意识到潜在的挑战和限制。

比如这些:

  • 1)Electron:Electron 应用程序可能会占用大量资源,可能会导致旧硬件上出现性能问题;
  • 2)Flutter:如果您主要是移动开发人员,那么使用 Flutter 进行桌面开发可能会涉及一个学习曲线;
  • 3)Tauri:作为一个相对较新的框架,与更成熟的选项相比,Tauri 可能拥有较小的社区和较少的第三方库;
  • 4)React Native:将 React Native 转换到桌面可能需要额外的努力,并且某些特定于平台的功能可能更难访问;
  • 5)Qt:Qt 的学习曲线,特别是对于刚接触 C++ 的开发人员来说,可能是一个挑战。

12、本文小结

为桌面应用程序开发选择正确的框架很大程度上取决于项目的具体要求,例如目标平台、性能预期、UI 需求和所需的开发体验。

如果正在寻找一个允许你利用 Web 技术的框架,Electron和React Native是不错的选择。Electron 拥有庞大的社区和广泛的预构建组件,而 React Native 提供强大的组件系统,并允许在移动和桌面平台之间重用代码。

如果性能和小包大小是优先考虑的,请考虑Flutter或Tauri。Flutter 提供快速的启动时间和流畅的动画,而 Tauri 则以其轻量级和低资源消耗而闻名。

如果你需要一个具有出色本机集成和本机外观的框架,Qt是一个可靠的选择。

如果你正在开发需要丰富的、可定制的用户界面的复杂应用程序,Flutter可能是最佳选择,因为它基于 widget 的开发方法。

还请各位开发者要记住,请考虑与每个框架相关的学习曲线,特别是如果你或团队尚不熟悉所涉及的技术。比如,Tauri 需要 Rust 或 C 的前置知识,而 Flutter 使用 Dart 做为预备知识。

13、相关资料

[1] Electron官方开发者手册

[2] Flutter官方手册

[3] Tauri官方手册

[4] React Native开发指南

[5] QT官方文档和手册

[6] 快速了解新一代跨平台桌面技术——Electron

[7] Electron初体验(快速开始、跨进程通信、打包、踩坑等)

[8] vivo的Electron技术栈选型、全方位实践总结

[9] 融云基于Electron的IM跨平台SDK改造实践总结

[10] 闲鱼IM基于Flutter的移动端跨端改造实践

[11] 网易云信基于Electron的IM消息全文检索技术实践


(本文已同步发布于:http://www.52im.net/thread-4598-1-1.html

posted @ 2024-01-11 10:58 Jack Jiang 阅读(80) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第31 期。

​[- 1 -] IM消息ID技术专题(一):微信的海量IM聊天消息序列号生成实践(算法原理篇)

[链接] http://www.52im.net/thread-1998-1-1.html

[摘要] 如何优雅地解决“消息序列号只要保证顺序性而不需要兼顾唯一性”的问题呢?这就是本文所要分享的内容,强烈建议深入理解和阅读。


[- 2 -] IM消息ID技术专题(二):微信的海量IM聊天消息序列号生成实践(容灾方案篇)

[链接] http://www.52im.net/thread-1999-1-1.html

[摘要] 本篇将会介绍 seqsvr 分布式容灾架构的演变。


[- 3 -] IM消息ID技术专题(三):解密融云IM产品的聊天消息ID生成策略

[链接] http://www.52im.net/thread-2747-1-1.html

[摘要] 本文要分享的是融云即时通讯云产品中的聊天消息ID生成算法和策略,一个19字节的ID就能包含:时间戳、消息类型、会话ID、序列号,小ID、大用途,值得借鉴!


[- 4 -]IM消息ID技术专题(四):深度解密美团的分布式ID生成算法

[链接] http://www.52im.net/thread-2751-1-1.html

[摘要] 对于美团的Leaf-segment这个ID生成方案,因为生成的ID全局唯一、全局有序,所以非常适合IM这种应用场景,这也是即时通讯网整理并分享给社区的原因。


[- 5 -] IM消息ID技术专题(五):开源分布式ID生成器UidGenerator的技术实现

[链接] http://www.52im.net/thread-2953-1-1.html

[摘要] 本文是专题系列文章的第5篇,专门介绍百度开源的分布式消息ID生成器UidGenerator的算法逻辑、实现思路、重点源码解读等,或许能带给你更多的启发。


[- -] IM消息ID技术专题(六):深度解密滴滴的高性能ID生成器(Tinyid)

[链接] http://www.52im.net/thread-3129-1-1.html

[摘要] 本文将要分享的是滴滴开源的分布式ID生成器Tinyid的技术原理、使用方法等等,希望能进一步为你打开这方面的技术视野。


[- 7 -] IM消息ID技术专题(七):深度解密vivo的自研分布式ID服务(鲁班)

[链接] http://www.52im.net/thread-4378-1-1.html

[摘要] 本文通过对分布式ID的3种应用场景、实现难点以及9种分布式ID的实现方式进行介绍,并对结合vivo业务场景特性下自研的鲁班分布式ID服务从系统架构、ID生成规则与部分实现源码进行分享,希望为本文的阅读者在分布式ID的方案选型或技术自研提供参考。


[- 8 -] IM开发宝典:史上最全,微信各种功能参数和逻辑规则资料汇总

[链接] http://www.52im.net/thread-3008-1-1.html

[摘要] 本文将根据微信官方目前已公开的资料,将它的一些常用功能参数和逻辑规则资料进行了汇总整理,希望能助力你的IM开发!


[- -]  IM开发干货分享:我是如何解决大量离线消息导致客户端卡顿的

[链接] http://www.52im.net/thread-3036-1-1.html

[摘要] 今天这篇不是原理性文章,而是为大家分享一下由笔者主导开发实施的IM即时通讯聊天系统,针对大量离线消息(包括消息漫游)导致的用户体验问题的升级改造全过程。


[- 10 -] 零基础IM开发入门(一):什么是IM系统?

[链接] http://www.52im.net/thread-3065-1-1.html

[摘要] 本系列文章将尽量从理论概念入手,通俗易懂的梳理IM中的基础技术概念和热门技术点,希望能帮你理清看似一团乱麻的IM知识体系,助你找到清晰的IM技术学习方向。


[- 11 -] 零基础IM开发入门(二):什么是IM系统的实时性?

[链接] http://www.52im.net/thread-3143-1-1.html

[摘要] 对于技术门外汉来说,到底什么是IM的“实时性”?该如何理解它?这就是本文想要讨论的主题。


[- 12 -] 零基础IM开发入门(三):什么是IM系统的可靠性?

[链接] http://www.52im.net/thread-3182-1-1.html

[摘要] 本篇主要讲解IM系统中的“可靠性”这个话题,内容尽量做到只讲原理不深入展开,避开深层次的技术性探讨,确保通俗易懂。


[- 13 -] 零基础IM开发入门(四):什么是IM系统的消息时序一致性?

[链接] http://www.52im.net/thread-3189-1-1.html

[摘要] 本文尽量以通俗简显的文字为你讲解IM消息时序一致性问题的产品意义、发生原因、解决思路等。


👉52im社区本周新文:《IM跨平台技术学习(十):快速对比跨平台框架Electron、Flutter、Tauri、React Native等》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2024-01-10 13:24 Jack Jiang 阅读(46) | 评论 (0)编辑 收藏

本文由字节跳动技术团队李晨光、匡建鑫、陈鉴平分享,本文有修订和改动。

1、引言

新媒体互动直播已成为了广大网民最重要的休闲娱乐方式之一。丰富的传统文化、新闻、竞技体育、法律、知识共享等内容,通过移动端互动直播的形式得以更加高效的展现传播,既让优质的直播内容可以实现爆发式传播扩散,又可以让用户有更多的机会感受,学习甚至主动参与直播互动。超低延时视频直播技术正在走上一条全新的发展之路。

本文将带您了解超低延时视频直播技术的优化和演进历程。

 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4587-1-1.html

2、系列文章

本文是系列文章中的第 11 篇,本系列总目录如下:

3、低延时直播技术的作用

网络基础设施升级、音视频传输技术迭代、WebRTC 开源等因素,驱动音视频服务时延逐渐降低, 使超低延时直播技术成为炙手可热的研究方向。实时音视频业务在消费互联网领域蓬勃发展, 并逐渐向产业互联网领域加速渗透。经历了行业第一轮的红利爆发期,我国实时音视频行业的场景效能逐渐深化,步入到理性增长阶段。

延时的指标选择很大程度上取决于用户与内容制作方的交互耦合程度,场景丰富多样。

在这些极端场景下,延时在用户侧希望越小越好,接近于实时通信的低延迟模式可以最大化地激发用户的参与感,无缝地与内容生产方产生互动效应,调动用户所见即所得的积极性。比如在主播秀场的PK、送礼、工会冲榜、打赏的活动关键环节,竞争双方的储值大户都希望实时地观察到自身主播在礼物刷榜后的反应,为后台运营决策团队或者后续活动策略提供第一时间的信息反馈。

下图体现了从技术/产品/运营的三方角度来综合思考低延时直播技术的作用;从外部-内部综合因素考虑技术的变迁对整个生态正向循环的影响。

4、传统直播技术中RTMP协议的延迟问题

RTMP 协议是最传统的直播协议,主播端采用 RTMP 协议推送 H.264/5 和 AAC 编码的视音频数据到云厂商 CDN 服务器进行转封装分发,端到端延迟一般控制在 3 到 7 秒。

问题是 RTMP 的可扩展性存在缺陷,同时对于延迟的进一步下探存在一定的技术困难。

RTMP 协议情况下:为了满足延时降低必然压缩播放器的下载缓冲区,这样会引发显著的卡顿问题,使得播放的观感产生不舒适的感受(延时下探至 2 秒以下)。

5、传统直播技术在实时互动场景中的不足

1)视频延时和弹幕交互的延时存在显著差异,问题聊天内容互动与视频传输图像节奏不匹配:

2)观众与主播互动形式单一,是单向内容传导无法做到双向(在 RTC 技术引入之前无法显著解决)。

3)单向传导的局限第一个方面表现在:观众端拉流传输无法做到根据网络情况自适应调节。用户只能以固定的码率进行流媒体传输无法做到动态感知,在网络情况实时变化的场景(比如弱网,移动基站切换等)固定单向码率传输有较大概率造成丢帧卡顿等因素影响观播体验。另一方面在网络条件更好时,固定码率传输无法动态提升视频传输码率(更高的画质带来更加舒适的体验)

4)在直播和连麦场景共存的互动直播场景下,主播采用传统RTMP推流在遇到连麦PK场景时,会产生推流/本地连麦合流/服务器连麦合流的切换问题,这种场景变换的切换会使得观众端产生瞬间的卡顿问题。如果采用基于webRTC直播技术的超低延时直播方案,这种推流--连麦逻辑的合流切换问题可以得到比较友好的解决(只需要改变服务器转发-订阅流通道的分发逻辑,不涉及推流媒体数据流的旁路调度切换)。

6、 超低延时直播与标准直播的区别

6.1超低延时直播

超低延时直播是近年来新兴起的一类应用。

如电商直播、赛事直播等场景,兼具高并发与低延时的特性,传统直播 3-20s 的时延难以满足其需求,但对实时互动的要求又不及视频会议等典型的实时音视频应用,无需将时延降低至 400ms 以下。

为此,超低延时直播融合了传统直播与实时音视频的技术架构,通过取长补短的方式实现了介于二者之间的端到端时延。

尽管针对超低延时直播厂商尚无一套标准的技术路径,但大体可以归纳为拉流协议、网络架构和推流协议三个方面的改造, 在实际应用过程中,厂商会平衡成本及性能指标等因素,在不同的协议和网络架构之间进行选择。

6.2传输层协议的差异

基于 UDP 协议的可靠性优化,为弱网对抗策略提供依据。

传统直播 FLV/RTMP 等采用的是 TCP 协议(或者 QUIC 协议)TCP 是牺牲传输实时性来换取数据完整性的可靠传输协议。

弱网环境下,其在数据传输前的“三次 握手”连接会带来较大延时。

而 UDP 作为不可靠的传输协议,其最大的优点为高实时性,但不保证数据的到达和排序。

实时音视频 产品(如 RTM 超低延时直播)往往采用 UDP 协议,并在此之上进行协议层与算法层的优化,来提高传输的可靠性与逻辑性。

相关文章可阅读:

  1. 网络编程懒人入门(五):快速理解为什么说UDP有时比TCP更有优势
  2. 技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解
  3. 不为人知的网络编程(六):深入地理解UDP协议并用好它
  4. 不为人知的网络编程(七):如何让不可靠的UDP变的可靠?

6.3UDP 协议的优化

UDP 协议往往和 RTP/RTCP 协议一起在实际应用中出现。

RTP 负责数据传输,其协议头中的序列号、 端口类型、时间戳等字段,可为数据包的分组、组装、排序提供逻辑依据。

RTCP 作为 RTP 的控制协议,负责对 RTP 的传输质量进行统计反馈,并为弱网对抗策略提供控制参数。

7、RTM 协议本身的演进历程

a=extmap:18 "http://www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp"

a=extmap:19 "uri:webrtc:rtc:rtp-hdrext:video:CompositionTime"

a=extmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range

a=extmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type

a=extmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp

a=extmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-config

RTP 使用 RTP 私有扩展头携带 DTS/CTS 值,每一帧 RTP 数据包通过 RFC5285-Header-Extension 扩展头携带该帧的 DTS 值,每一帧首个 RTP 包和 VPS/SPS/PPS 包通过 RFC5285-Header-Extension 扩展头携带该帧的 CTS 值,通过 PTS = DTS + CTS 计算当前帧的时间戳。用于启播快速音画同步和播放器播控逻辑精准音画同步。

扩展头携带帧的起始/结束序号:如果首帧的前几个包丢失,那么可根据起始序号快速发起重传加快首帧;如果当前帧的后几个包丢失,那么可根据该帧的结束序号快速发起重传,降低延时,减少卡顿。

扩展头携带帧的类型:如果携带并解析了正确的帧类型,客户端可以不用解析 metadata ;同时在弱网情形,客户端可以跳过 B 帧直接解码 P 帧,加速出帧并减少潜在卡顿。

扩展头携带 P 帧的参考帧信息:如果发生弱网情形,那么客户端可以依照扩展头指定的参考帧关系及其对应时间戳,跳过 B 帧解码 ,减少卡顿发生。

为了加速信令交互的速度,CDN 可以在某些条件下不去查询媒体信息,直接向客户端返回支持的音视频能力;此时 SDP 的媒体描述中将不包含有具体的音视频配置详细信息。在音频层面,此时AnswerSDP 中不包含 aac 解码所需的头信息;此时我们需要采取 RTP 扩展头模式携带 AAC-Config 供客户端在 RTP 收包时刻自行解析处理完成解码动作,作用是减少信令交互时间,提升拉流成功率。

miniSDP 信令标准实现部分(抖音)。

CDN 信令异步回源。

RTP 携带扩展头组成部分。

8、WebRTC 协议在直播播放器的移植

RTM 低延时直播基于 WebRTC 技术衍生,基于 WebRTC 标准构建点到点传输一般有如下几个步骤:

  • 1)通信双方要进行媒体协商,会话详细规范即 SDP(Session Description Protocol) 交互;
  • 2)随后进行交互式网络地址协商(查询对端真实 IP 地址)准备构建媒体传输通道;
  • 3)当上述条件准备完毕即进入最终的 Peer to Peer 点对点媒体数据传输。

信令部分客户端-服务器单独开发,利用了 SDP 标准报文模式。媒体传输部分采用开源的 WebRTC 框架和字节自研的实时音视频媒体引擎进行媒体传输。

9、RTC 信令协议的改造升级

MiniSDP压缩协议:https://github.com/zhzane/mini_sdp

标准 SDP 比较冗长(5-10KB 左右),不利于快速高效传输。在直播场景下,会尤其影响首帧时间。

MiniSDP 对标准 SDP 文本协议进行高效能压缩,将原生 SDP 转换成更小的二进制格式,使其能够通过一个 UDP 包来传输。

降低信令交互时间,提高网络传输效能,降低直播拉流首帧渲染时间,提高拉流秒开率/成功率等 QoS 统计指标。

10、CDN对RTM 信令的异步回源优化

降低 RTM 信令交互时间,降低 RTM 拉流首帧渲染时间。

原来的流程在服务端缓存不命中时需要等待回源拿到数据,才能返回带有 AacConfig 信息的 AnswerSDP。客户端收到 AnswerSDP 后发送 STUN,而服务端只能在收到 STUN 才能开始下发数据。

如下图左:当异步回源情况下,服务端不再等待回源结果直接返回 AnswerSDP,之后回源和WebRTC 建连流程同步进行。

如上图右:等到 WebRTC 建连成功且回源拿到数据立即下发 RTP 数据。

11、视频渲染卡顿的优化(百秒卡顿平均降低4秒)

改善人均看播时长,改变 RTC 引擎的组帧/解码策略;禁止 RTC 在低延时模式下的丢帧,改善直播的视频渲染卡顿。

传统的 RTC 场景优先保时延,全链路会触发各种丢帧(包括但不限于解码模块,网络模块),FLV 直播场景会优先保证观播体验(不丢帧,良好的音画同步效果)。

RTM 要想减少卡顿,取得 qoe 的收益,播控策略需进行定制化,定制逻辑修改点:

1)确保不会由于软解的解码耗时或者硬解的 dequeuinputbuffer 等其它 api 操作阻塞 jitterbuffer ,内核层有一层强制的音画同步逻辑,可以确保音视频的播放体验;

2)同时上层在监控网络模块和解码模块的缓存长度,有相应的兜底逻辑:

  • a. 判断硬解确实解不过来,dec_cache_frames 过多,上报错误,会降级到软解;
  • b. jitterbuffer 异常,缓存的 frame_list 过多,触发播放器异常逻辑,上报错误,重新拉流。

12、RTM播控逻辑的优化

改善移动端看播渗透,RTC 统一内核方案天生存在缺陷( MediaCodec 硬件解码器初始化耗时久)。将 RTM 视频解码模块从 RTC 内核中迁移至 TTMP 播放内核,复用了 FLV 的视频解码模块( MediaCodec 避免重新初始化)。显著的降低了安卓平台的首帧渲染时间,提升了拉流的成功率。

RTC 内核通用逻辑:

改进的 RTM 内核播控逻辑:

13、相关文章

[1] TCP/IP详解 - 第11章·UDP:用户数据报协议

[2] TCP/IP详解 - 第17章·TCP:传输控制协议

[3] 零基础入门:基于开源WebRTC,从0到1实现实时音视频聊天功能

[4] 实时音视频入门学习:开源工程WebRTC的技术原理和使用浅析

[5] 零基础快速入门WebRTC:基本概念、关键技术、与WebSocket的区别等

[6] 学习RFC3550:RTP/RTCP实时传输协议基础知识

[7] 基于RTMP数据传输协议的实时流媒体技术研究(论文全文)

[8] 技术扫盲:新一代基于UDP的低延时网络传输层协议——QUIC详解

[9] 让互联网更快:新一代QUIC协议在腾讯的技术实践分享

[10] 实时音视频面视必备:快速掌握11个视频技术相关的基础概念

[11] 实时音视频开发理论必备:如何省流量?视频高度压缩背后的预测技术

[12] 移动端实时音视频直播技术详解(一):开篇

[13] 直播系统聊天技术(九):千万级实时直播弹幕的技术实践

[14] 在线音视频直播室服务端架构最佳实践(视频+PPT) [附件下载]

[15] 视频直播技术干货:一文读懂主流视频直播系统的推拉流架构、传输协议等

(本文已同步发布于:http://www.52im.net/thread-4587-1-1.html

posted @ 2024-01-04 11:45 Jack Jiang 阅读(72) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第30 期。

​[- 1 -] 全面掌握移动端主流图片格式的特点、性能、调优等

[链接] http://www.52im.net/thread-1802-1-1.html

[摘要] 本文我们一起全面分析学习目前主流和新兴的几种图片格式的特点、性能、调优等,以及相关开源库的选择,希望能为您的移动端应用(包括本社区主要讨论的即时通讯应用)中的图片优化带来一些启发。


[- 2 -] 最火移动端跨平台方案盘点:React Native、weex、Flutter

[链接] http://www.52im.net/thread-1870-1-1.html

[摘要] 本篇主要以react-native、weex、flutter,深入聊聊当前最火的这3种跨平台移动开发方案的实现原理、现状与未来。至于为什么只讲它们,因为对比ionic、phoneGap,它们更于 “naive” (˶ ⁻̫ ˵)。看完本篇,相信你会对于当下跨平台移动开发的现状、实现原理、框架的选择等有更深入的理解。


[- 3 -] 子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践

[链接] http://www.52im.net/thread-1961-1-1.html

[摘要] 本文内容来自对网易云信首席架构师周梁伟的采访,采访内容主要围绕网易云信这种海量用户IM云平台的关键技术难点以及对应的技术实践。


[- 4 -] IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列

[链接] http://www.52im.net/thread-1979-1-1.html

[摘要] 消息是互联网信息的一种表现形式,是人利用计算机进行信息传递的有效载体,比如即时通讯网坛友最熟悉的即时通讯消息就是其具体的表现形式之一。


[- 5 -] 微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)

[链接] http://www.52im.net/thread-1999-1-1.html

[摘要] 本篇将会介绍 seqsvr 分布式容灾架构的演变。


[- 6 -] 阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史

[链接] http://www.52im.net/thread-2050-1-1.html

[摘要] 阿里数据库事业部研究员张瑞,将为你讲述双11数据库技术不为人知的故事。


[- 7 -] 自已开发IM有那么难吗?手把手教你自撸一个Andriod版简易IM (有源码)

[链接] http://www.52im.net/thread-2671-1-1.html

[摘要] 本文不是一篇即时通讯理论文章,文章内容全部由实战代码组织而成。


[- 8 -] 融云技术分享:解密融云IM产品的聊天消息ID生成策略

[链接] http://www.52im.net/thread-2747-1-1.html

[摘要] 本文要分享的是融云即时通讯云产品中的聊天消息ID生成算法和策略,一个19字节的ID就能包含:时间戳、消息类型、会话ID、序列号,小ID、大用途,值得借鉴!


[- -]  IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!

[链接] http://www.52im.net/thread-2759-1-1.html

[摘要] 本文将分析传统数据库(即SQL数据库)存在的一些问题,以及盘点目前市面上几大类 NoSQL 特性、优缺点等,希望给大家提供一些在不同业务场景下存储技术选型方面的参考。


[- 10 -] 适合新手:从零开发一个IM服务端(基于Netty,有完整源码)

[链接] http://www.52im.net/thread-2768-1-1.html

[摘要] 本文写的比较浅显但不太易懂,建议结合代码一起来读,文章配套的完整源码请从本文文末 “11、完整源码下载” 处下载!


[- 11 -] 拿起键盘就是干:跟我一起徒手开发一套分布式IM系统

[链接] http://www.52im.net/thread-2775-1-1.html

[摘要] 本文记录了我开发的一款面向IM学习者的 IM系统——CIM(全称:CROSS-IM),同时提供了一些组件帮助开发者构建一款属于自己可水平扩展的 IM。


[- 12 -] 适合新手:手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)

[链接] http://www.52im.net/thread-2988-1-1.html

[摘要] 本文适合有一定网络通信技术基础的IM新手阅读。如果你对网络编程,以及IM的一些理论知识知之甚少,请务必首先阅读:《新手入门一篇就够:从零开发移动端IM》,按需补充相关知识。


[- 13 -] IM里“附近的人”功能实现原理是什么?如何高效率地实现它?

[链接] http://www.52im.net/thread-2827-1-1.html

[摘要] 本文将简要的为你讲解“附近的人”的基本理论原理,并以Redis的GEO系列地理位置操作指令为例,理论联系实际地为你讲解它们是如何被高效实现的。


[- 14 -] IM开发基础知识补课(七):主流移动端账号登录方式的原理及设计思路

[链接] http://www.52im.net/thread-2863-1-1.html

[摘要] 本文将分享几种典型的移动端账号登陆方式的技术原理,以及设计思路,理解后,完全可以快速实施于你的各种应用系统(并不限于IM系统)中。


[- 15 -] IM“扫一扫”功能很好做?看看微信“扫一扫识物”的完整技术实现

[链接] http://www.52im.net/thread-2887-1-1.html

[摘要] 本文将详细为你解密微信“扫一扫识物”功能背后的技术秘密。


[- 16 -] IM要做手机扫码登录?先看看微信的扫码登录功能技术原理

[链接] http://www.52im.net/thread-2941-1-1.html

[摘要] 本文将以轻松活泼的语言形式,为你分析和讲解微信手机扫码登录的技术原理,希望在你的IM中开发此功能时有所启发。


👉52im社区本周新文:《视频直播技术干货(十一):超低延时视频直播技术的演进之路》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2024-01-03 11:57 Jack Jiang 阅读(14) | 评论 (0)编辑 收藏

     摘要: 本文由字节跳动技术团队杨晨曦分享,本文有修订和改动。1、引言本文将带你一起初步认识Thrift的序列化协议,包括Binary协议、Compact协议(类似于Protobuf)、JSON协议,希望能为你的通信协议格式选型带来参考。  技术交流:- 移动端IM开发入门文章:《新手入门一篇就够:从零开发移动端IM》- 开源IM框架源码:https://github.com/JackJ...  阅读全文

posted @ 2023-12-28 10:52 Jack Jiang 阅读(51) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第29 期。

[- 1 -] 谈谈移动端 IM 开发中登录请求的优化

[链接] http://www.52im.net/thread-282-1-1.html

[摘要] 到底是“登陆”还是“登录”?这是很多处女坐开发者纠结的问题,不过它不是本文本讨伦的内容。本文将针对移动端IM的登陆功能给出相应的优化建议。


[- 2 -] 移动端IM登录时拉取数据如何作到省流量?

[链接] http://www.52im.net/thread-787-1-1.html

[摘要] 移动网络时代,手机的流量是个很昂贵的资源(至少暂时是这样)。一个典型的移动端IM在登录后,往往要向服务器同步非常多的数据,如果处理的不好是很费流量的,那么从技术上来讲,有没有节省流量的方法呢?这就是本文要讨论的话题。


[- 3 -] 浅谈移动端IM的多点登录和消息漫游原理

[链接] http://www.52im.net/thread-867-1-1.html

[摘要] 本文将展开聊聊移动端IM“多点登陆”与“消息漫游”的原理。


[- 4 -] 完全自已开发的IM该如何设计“失败重试”机制?

[链接] http://www.52im.net/thread-280-1-1.html

[摘要] 如何设计好这个失败重试的机制,使得客户端能做好失败重试,服务器有能够排除这种重复消息,但是排重处理不太复杂?


[- 5 -] 通俗易懂:基于集群的移动端IM接入层负载均衡方案分享

[链接] http://www.52im.net/thread-802-1-1.html

[摘要] 本文将以基于TCP数据传输协议的移动端IM为例,通过循序渐进地方式,分享如何构建一个基于分布式集群的移动端IM接入层的设计和实现。


[- -] 微信对网络影响的技术试验及分析(论文全文)

[链接] http://www.52im.net/thread-195-1-1.html

[摘要] 本文来自论文《微信对网络影响的技术试验及分析》,文中研究了微信对现今移动网络的影响,对于即时通讯开发人员来说,文中的某些数据和研究结果,对于实现类似的技术,有一定的参考和借鉴意义。即时通讯网(52im.net)现全文收录之。


[- 7 -] 即时通讯系统的原理、技术和应用(技术论文)

[链接] http://www.52im.net/thread-218-1-1.html

[摘要] 首先,介绍即时通信的概念、特点和技术原理,较为全面地剖析了实现即时通信系统涉及的关键技术,包括即时通信传输协议、相关安全技术和音/视频编解码技术等;其次,简要概述了即时通信系统在我校的应用情况;最后,说明当前即时通信工具存在的问题及其发展趋势。


[- 8 -] 开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀

[链接] http://www.52im.net/thread-447-1-1.html

[摘要] 本文将简要介绍TeamTalk开源的过去和现在,为打算研究和采用TeamTalk的同行提供一定程度的参考。文中所涉及内容如有不妥,还请各位看官见谅。


[- -]  QQ音乐团队分享:Android中的图片压缩技术详解(上篇)

[链接] http://www.52im.net/thread-1208-1-1.html

[摘要] 实际在生产环境下,群消息的发送都会想尽办法进行压缩,并开展各种改善性能的处理办法,而不是像上述举例里的直接扩散写(即2000人群里,一条消息被简单地复制为2000条一对一的消息投递)。具体有哪些优先策略?本文或许可以带给你一些启发。


[- 10 -] QQ音乐团队分享:Android中的图片压缩技术详解(下篇)

[链接] http://www.52im.net/thread-1212-1-1.html

[摘要] 关于压缩图片在诸如即时通讯应用场景下的好处,我们就不再赘述,不言自明。本篇将承接上篇《QQ音乐团队分享:Android中的图片压缩技术详解(上篇)》,继续讨论图片的尺寸压缩和常用的几种尺寸压缩算法。


[- 11 -] 腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率

[链接] http://www.52im.net/thread-675-1-1.html

[摘要] 本文内容是由腾讯TMQ专项测试团队针对手机QQ图片上传速度和成功率问题,在各种复杂移动网络环境下的优化实践总结和整理而成。文章虽是针对手机QQ图片上传这一特定业务功能,但内容中大量涉及复杂移动网络环境下无线网络的特性、特点以及相关第一手测试数据,都是非常珍贵的,尤其值得移动端IM开发、消息推送这种深度依赖移动网络的应用开发者借鉴和参考。


[- 12 -] 腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)

[链接] http://www.52im.net/thread-696-1-1.html

[摘要] 本文将给读者们一个一年多以前为公司的某产品成功优化网络流量的案例。速度、成功率与流量正好是 Apps 网络优化的几大重点,希望本文我们分享的思路能够给诸位正在开展或将来会开展此类工作的读者们一些启发。


[- 13 -] 腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(下篇)

[链接] http://www.52im.net/thread-697-1-1.html

[摘要] 本篇中将详细介绍我们的具体分析方法和实践优化思路,以及在优化过程中总结出来的法则等。


[- 14 -] 如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源

[链接] http://www.52im.net/thread-684-1-1.html

[摘要] 本文正文内容引用了微信开发团队的资料。


[- 15 -] 基于社交网络的Yelp是如何实现海量用户图片的无损压缩的?

[链接] http://www.52im.net/thread-1191-1-1.html

[摘要] 研究Yelp的极致图片压缩技术,或许能给即时通讯开发者同行带来一定的借鉴意义,而这也是此文的意义所在。


[- 16 -] 腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)

[链接] http://www.52im.net/thread-1559-1-1.html

[摘要] 本次文章跟大家分享如何在保障质量(指的是图片质量、音视频质量)前提下所做的带宽和网络流量压缩,进而达到运营成本的优化。


[- 17 -] 腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)

[链接] http://www.52im.net/thread-1560-1-1.html

[摘要] 本文接上篇《腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》,继续腾讯公司分享如何在保障质量(指的是图片质量、音视频质量)前提下所做的带宽和网络流量压缩,进而达到运营成本的优化。


[- 18 -] 为什么说即时通讯社交APP创业就是一个坑?

[链接] http://www.52im.net/thread-1619-1-1.html

[摘要] 所以今天,我将尽量试着以用户的眼光,去描述这样一种现实:什么拳打QQ、脚踩微信,自嗨式的创业就像浮云一样......


👉52im社区本周新文:《IM通讯协议专题学习(十):初识 Thrift 序列化协议》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-12-27 15:23 Jack Jiang 阅读(47) | 评论 (0)编辑 收藏

本文由冰河分享,作者博客 binghe.gitcode.host,原题“这套分布式IM即时通讯系统如何写到简历上?我给你整理好了!”,本文有修订和改动。

1、引言

分布式IM即时通讯系统本质上就是对线上聊天和用户的管理。

针对聊天本身来说,最核心的需求就是:发送文字、图片、文件、语音、视频、消息缓存、消息存储、消息未读、已读、撤回,离线消息、历史消息、单聊、群聊,多端同步,以及其他一些需求。

对用户管理来说,存在的需求包含:添加好友、查看好友列表、删除好友、查看好友信息、创建群聊、加入群聊、查看群成员信息、退出群聊、修改群昵称、拉人进群、踢人出群、解散群聊、填写群公告、修改群备注以及其他用户相关的需求等。

为了更好的理解分布式IM即时通讯系统的设计,我站在架构师的角度,在充分了解系统需求、业务流程和技术流程后,从全局视角为系统设定方案目标,对技术方案进行选型,对系统进行总体架构设计和分层架构设计,并梳理清楚发送消息的交互链路、单聊和群聊的交互链路。希望对你有帮助。

 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4564-1-1.html

2、方案目标

在进行技术选型与总体架构设计之前,需要明确一个事项,就是系统无论采用哪种方案,采用哪种架构设计都需要明确这种方案的业务目标、技术目标和架构目标,并在研发过程中不断评估系统的总体性能表现,发现系统瓶颈并不断进行优化。

总体上,我们搭建和开发的分布式IM即时通讯系统,需要满足如下方案目标。

具体是:

  • 1)业务目标:满足需求设计篇章中的各类需求场景;
  • 2)技术目标:支持无限扩容,百万用户同时在线聊天;
  • 3)架构目标:高并发、高性能、高可用、可监控、可预警、可伸缩,支持无限扩展。

3、技术选型

在技术选型上,除了采用SpringBoot等基础框架外,也会采用容器化方案。

同时,考虑到为了尽量降低技术门槛,在整个分布式IM即时通讯系统的技术选型中,主要采用市面上比较流行的技术框架和方案。

具体选型如下所示:

  • 1)开发框架:SpringBoot、SpringCloud、SpringCloud Alibaba、Dubbo;
  • 2)缓存:Redis分布式缓存+Guava本地缓存;
  • 3)数据库:MySQL、TiDB、HBase;
  • 4)流量网关:OpenResty+Lua;
  • 5)业务网关:SpringCloud Gateway + Sentinel;
  • 6)持久层框架:MyBatis、Mybatis-Plus;
  • 7)服务配置、服务注册与发现:Nacos;
  • 8)消息中间件:RocketMQ;
  • 9)网络通信Netty
  • 10)文件存储:Minio;
  • 11)日志可视化治理:ELK;
  • 12)容器化管理:Swarm、Portainer;
  • 13)监控:Prometheus、Grafana;
  • 14)前端:Vue;
  • 15)单元测试:Junit;
  • 16)基准测试:JMH;
  • 17)压力测试:JMeter。

4、初步架构设计

对于IM即时通讯系统来说,涵盖了即时通讯后端服务、大后端平台、SDK接入服务、OpenAI接入服务、大前端UI,我相信不少小伙伴多多少少能够画出IM即时通讯系统的架构图,大致如下图所示。

 

其实,这种这种架构设计也比较常见,在这种架构设计中,Kong/Openresty/Nginx只做负载均衡和反向代理,研发人员更多的是关注业务层和基础层的开发,流量比较小时,这种架构设计一般不会有什么问题。但是一旦流量比较大,用户调用后端平台的接口发送消息时,即时通讯SDK同步调用即时通讯服务的接口就会出现性能问题。

因为每个终端同时只能与一个IM即时通讯服务实例建立连接,如果大量的用户终端恰好都与一个IM即时通讯服务建立连接,那即时通讯SDK频繁同步调用同一个IM即时通讯服务的接口就会出现性能瓶颈。此时,出现性能瓶颈时,不仅仅会影响到IM即时通讯服务,也会对后端平台接收请求的业务造成一定的影响。

5、架构设计优化

既然上节图中所示的架构设计存在性能瓶颈,那我们如何进行优化呢?

为此我们在前图基础上进行了优化,优化后的架构如下图所示。

对比两图可以看出,在屏蔽掉技术实现细节的前提下,我们将对业务的校验和流量管控进行前置化,放大Kong/OpenResty/Nginx的职责,使得这些软件不仅具备反向代理和负载均衡的功能,还能实现限流、黑白名单、流量管控、业务校验等功能。

也就是说,在这种架构模式下,我们充分发挥了整个分布式IM即时通讯系统的入口职责,充分利用Kong/OpenResty/Nginx的高并发、高吞吐量的能力,尽量将大部分无效请求挡在整个系统之外。例如,用户在没登录系统的前提下,就尝试调用发送消息、添加好友、添加群组等等接口。这样会大大减轻后台平台的业务压力。

除了在Kong/OpenResty/Nginx中实现限流、黑白名单、流量管控、业务校验等功能外,我们还引入了业务网关集群,实现限流、降级、熔断、流控、校验、鉴权等功能,进一步保证下游系统的稳定性和安全。

为了解决大量用户终端恰好连接到同一个IM即时通讯服务实例,IM即时通讯SDK频繁调用同一个IM即时通讯服务实例的接口造成的性能问题。我们在IM即时通讯服务SDK与IM即时通讯服务之间引入了RocketMQ集群。

IM即时通讯服务集群中的每一个IM即时通讯服务实例在集群中都有一个唯一的ID,并且每个IM即时通讯服务实例在启动后,只会监听RocketMQ中与自身ID相关的Topic。这样每个IM即时通讯服务只会收到与自身ID相关的Topic中的消息,不会接收所有的消息。

当用户登录系统后,就会与IM即时通讯服务建立长连接,并且会以用户ID和终端为Key,以IM即时通讯服务的ID为value,将其存储到分布式缓存中。同时,会以用户ID和终端为Key,以用户终端与IM即时通讯服务建立的长连接为value,将其存储到IM即时通讯服务本地内存中。

当用户调用后端平台的接口发消息时,会带上目标用户的ID,并且在IM即时通讯SDK中会指定用户登录的终端设备,最终会通过IM即时通讯SDK向RocketMQ发送消息。

此时IM即时通讯SDK会根据目标用户ID和终端从分布式缓存中获取目标用户连接的IM即时通讯服务的ID,并向此ID相关的Topic发送消息。此时与目标用户建立长连接的IM即时通讯服务就会接收到RocketMQ中的消息,随后根据用户ID和终端从本地缓存中获取到与用户终端建立的长连接,并基于此长连接向用户推送消息。

另外,在实际实现中,为了避免大量用户同时只连接IM即时通讯服务集群中的某一个服务实例,会对用户连接的IP、浏览器指纹、手机设备等做Hash和取模运算,使其尽量均匀分布到集群中的每一个服务实例上。

那么问题来了,这种架构设计还有进一步优化的空间吗?

6、容器化架构设计

为进一步增强分布式IM即时通讯系统的性能、可用性和弹性伸缩能力,我们可以对分布式IM即时通讯系统进行容器化架构设计,如下图所示。

可以看到,我们对分布式IM即时通讯系统的架构设计进行了进一步优化,采用了容器化架构设计。在原有架构的基础上,我们进行了如下改进和优化。

1)基础支撑服务:基础支撑服务会由各种基础中间件、数据存储服务、以及监控服务实现,包含:MySQL数据库、TiDB数据库、HBase、Redis缓存、RocketMQ消息队列、Prometheus监控和Portainer容器管理等基础中间件实现,基础支撑服务会对整个分布式IM即时通讯系统提供最基础的数据、传输、监控和容器管理等服务。

2)容器化:在容器化层面,会通过Docker、Swarm和Portainer实现,其中,会基于Swarm和Portainer对容器化进行管理。

3)其他基础性功能实现:除了上述分层架构外,对于建设分布式IM即时通讯系统来说,还要考虑异常监控、服务注册与发现、可视化、服务降级与兜底数据、服务限流、服务容灾、容量规划与扩缩容和全链路压测等。

7、DDD分层业务架构设计

在分布式IM即时通讯系统中,不管是大后端平台,还是IM即时通讯服务,我们都会对业务层的代码采用分层业务架构。

这里,可以借鉴DDD的分层架构思想,将代码总体上分成展示层、应用层、领域层和基础设施层四个层次。

但是,考虑到分布式IM即时通讯系统的特殊性,又不会严格按照DDD的原则来设计代码分层,具体按照如下图所示。

可以看到,分布式IM即时通讯系统会借鉴DDD的设计思想,但是不会完全按照DDD的方式进行设计。

1)展示层:展示层,也叫做用户UI层,是DDD设计的最上层,对外提供API接口,接收客户端请求,解析参数,返回结果数据,并对异常进行处理。

2)应用层:应用层,也叫做Application层,应用层主要处理容易变化的业务场景,可对相关的事件、调度和其他聚合操作进行相关的处理。

3)领域层:领域层,也叫做Domain层,领域层可以说是DDD设计的精髓所在,它是将业务系统中相对不变的部分抽象出来封装成领域模型。在分布式IM即时通讯系统的设计中,领域层基本不会依赖其他层,也不会依赖基础设施层,这里是与DDD设计存在区别的地方。

4)基础设施层:基础设施层,也叫做Infrastructure层,基础设施层会对其他各层提供通用的基础能力,在分布式IM即时通讯系统中,就包括了缓存、通用工具类、消息、系统的持久化机制等。

8、总体IM消息交互链路

在分布式IM即时通讯系统中,我们忽略掉其他一些细节信息,重点关注下发送消息的交互链路逻辑。不管是单聊还是群聊,最终都需要通过IM即时通讯服务将消息推送给用户的终端。此时发送消息的流程如下图所示。

可以看到:用户在分布式IM即时通讯系统发送消息时,不管是单聊还是群聊,最终的消息都会推送到用户登录的终端设备上。假设此时用户A给用户B发送消息,或者用户A和用户B在同一个群组,用户A向群组发送消息,用户B接收消息的主要流程如下。

具体是:

  • 1)用户A调用后端平台的接口向用户B发送消息,并且发送的消息中会带有用户B的ID以及终端信息;
  • 2)后端平台将消息缓存起来,并且会将消息异步写入消息库;
  • 3)后端平台从Redis中获取用户B连接的IM即时通讯服务的ID;
  • 4)后端平台获取到用户B连接的IM即时通讯服务的ID后,会向RocketMQ中用户B连接的IM即时通讯服务ID对应的Topic发送消息;
  • 5)IM即时通讯服务会监听自身服务ID对应的RocketMQ中Topic的消息,此时,用户B连接的IM即时通讯服务会接收到消息;
  • 6)IM即时通讯服务接收到消息后,会根据用户B的ID以及终端信息从缓存中获取用户B与IM即时通讯服务建立的连接,并且通过这个连接向用户B推送消息。

要实现如上发送消息的流程,前提是要满足如下条件:

  • 1)后端平台满足分布式条件,可随时横向扩展;
  • 2)IM即时通讯服务满足分布式条件,可随时横向扩展;
  • 3)每个启动的IM即时通讯服务实例在集群中都有一个唯一的ID;
  • 4)每个IM即时通讯服务,都只监听自身ID对应的RocketMQ中Topic的消息;
  • 5)用户登录分布式IM即时通讯系统后,会与IM即时通讯服务建立长连接,并且会根据用户ID和所在的终端缓存长连接,同时会根据用户ID和所在的终端将连接的IM即时通讯服务的ID缓存到Redis;
  • 6)用户发送消息时,会根据目标用户的ID和终端从Redis中获取IM即时通讯服务的ID,进而向当前IM即时通讯服务的ID对应的RocketMQ的Topic发送消息;
  • 7)对应的IM即时通讯服务监听并接收到RocketMQ消息后,会根据目标用户的ID和终端从缓存中获取到用户的连接信息,向目标用户推送消息。

9、IM单聊交互链路

单聊就是在分布式IM即时通讯系统中,一个用户直接与另外一个用户聊天,也就是一对一的聊天。在这种场景下,很有可能单聊的两个用户中,出现用户不在线的情况。

例如:用户A给用户B发送消息时,用户B可能不在线。

此时,我们就需要将用户A向用户B发送的消息存储起来。

其实,在我们实现的分布式IM即时通讯系统中,无论把用户B是否在线,都会存储消息记录。当用户B登录系统后,将消息同步给用户B,如下图所示。

可以看到,用户A向用户B发送消息时:

  • 1)如果用户B在线,就可以按照发送消息的交互链路向用户B发送消息了;
  • 2)如果用户B不在线,此时就无法向用户B正常推送消息。当用户B登录分布式IM即时通讯系统后,就会调用后端平台的接口拉取所有未读消息,并通过用户B在线流程向用户B推送消息。

10、IM群聊交互链路

群聊就是在分布式IM即时通讯系统中,多个用户在同一个群组中进行聊天。

此时在发送消息时,我们可以通过群组ID找出群内所有在线的用户,将消息即时发送给在线的用户。

那些未在线的用户就按照单聊未在线的用户进行处理,如下图所示。

可以看到,群聊的交互链路流程如下所示:

  • 1)用户调用后端平台的接口向群组发送消息;
  • 2)后端平台将消息缓存并异步写入消息库;
  • 3)由于是向群组发送消息,群里有多个用户,此时就会从Redis中获取所有用户连接的IM即时通讯服务ID列表;
  • 4)对用户按照服务ID分组,将相同服务ID下的用户分在同一个逻辑分组里,方便后续推送消息,并且会记录未在线的用户列表;
  • 5)循环向每个服务ID对应的RocketMQ中的Topic发送消息;
  • 6)广播处理未在线用户的未读消息ID;
  • 7)IM即时通讯服务会监听自身服务ID对应的Topic,会随时接收推送到自身服务的消息;
  • 8)当IM即时通讯服务接收到消息后,此时用户掉线,或者用户不在线,向用户推送消息就会失败,或者未查询到用户与IM即时通讯服务建立的连接,就不会向用户推送消息;
  • 9)当用户登录分布式IM即时通讯系统后,会从后端平台拉取历史(离线)消息,并通过用户在线的流程,向用户推送消息;

好了,看到这里,你明白如何设计一个高度可扩展的分布式IM即时通讯系统了吗?

11、相关资料

[1] 浅谈IM系统的架构设计

[2] 简述移动端IM开发的那些坑:架构设计、通信协议和客户端

[3] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[4] 一套原创分布式即时通讯(IM)系统理论架构方案

[5] 移动端IM中大规模群消息的推送如何保证效率、实时性?

[6] 一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等

[7] 一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等

[8] 从新手到专家:如何设计一套亿级消息量的分布式IM系统

[9] 企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等

[10] 融云技术分享:全面揭秘亿级IM消息的可靠投递机制

[11] 阿里IM技术分享(三):闲鱼亿级IM消息系统的架构演进之路

[12] 基于实践:一套百万消息量小规模IM系统技术要点总结

[13] 跟着源码学IM(十):基于Netty,搭建高性能IM集群(含技术思路+源码)

[14] 一套十万级TPS的IM综合消息系统的架构实践与思考

[15] 得物从0到1自研客服IM系统的技术实践之路

[16] 海量用户IM聊天室的架构设计与实践

[17] 史上最通俗Netty入门长文:基本介绍、环境搭建、动手实战

[18] 新手入门:目前为止最透彻的的Netty高性能原理和框架架构解析

[19] 写给初学者:Java高性能NIO框架Netty的学习方法和进阶策略

[20] 手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制

[21] 史上最强Java NIO入门:担心从入门到放弃的,请读这篇!

(本文已同步发布于:http://www.52im.net/thread-4564-1-1.html

posted @ 2023-12-21 11:29 Jack Jiang 阅读(53) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第28 期。

[- 1 -] 新手入门一篇就够:从零开发移动端IM

[链接] http://www.52im.net/thread-464-1-1.html

[摘要] 本文将以新手的视角引导你阅读相关文章,便于你从零开发一个移动端IM做好方方面面的知识准备:包括但不限于网络编程基础、通信协议的选型、IM的架构设计等等。文笔有限,如有不妥之处还请批评指正,希望对你有用。

[- 2 -] 移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

[链接] http://www.52im.net/thread-1587-1-1.html

[摘要] 本文的目的,就是希望以通俗易懂的语言,帮助移动端IM开发者更好地理解移动网络的各种特性,使得开发出的功能能更好地适应移动网络,给用户带来更好的使用体验。

[- 3 -] 移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

[链接] http://www.52im.net/thread-1588-1-1.html

[摘要] 本文将针对上篇中提到的特性,结合我们的实践经验,总结了四个方法来追求极致的“爽快”:快链路、轻往复、强监控、多异步,从理论讲到实践、从技术讲到产品,理论联系实际,举一反三,希望给您带来启发。

[- 4 -] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[链接] http://www.52im.net/thread-1470-1-1.html

[摘要] 这篇文章和大家聊下从移动端客户端的角度所关注的IM消息可靠性和送达机制

[- 5 -] 现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

[链接] http://www.52im.net/thread-1413-1-1.html

[摘要] 本文整理的有关内容,对于移动端即时通讯IM应用来说,同样具有启发意义

[- 6 -] 腾讯技术分享:社交网络图片的带宽压缩技术演进之路

[链接] http://www.52im.net/thread-1391-1-1.html

[摘要] 为了进一步降低运营带宽成本,减小用户访问流量及提升页面加载速度,社交网络 CDN运维紧跟行业图片优化趋势,创新引入WebP、SharpP、自适应分辨率、Guetzli等图像压缩技术到现网,经过三年多的多部门联合攻关,已逐渐形成一套覆盖全图片类型(JPEG、JPG、PNG、WebP、GIF)多场景的图片压缩运营体系,适用于各类型终端,每年节约外网带宽几百G。

[- 7 -] 小白必读:闲话HTTP短连接中的Session和Token

[链接] http://www.52im.net/thread-1686-1-1.html

[摘要] 本文的写作目的是以最白话地方式,通俗易懂的为你讲清HTTP协议中的Session和Token等概念,希望读完全文,您仍能满怀信心,继续义无反顾地跳入程序员这个职业深坑 ^_^。更深入的技术细节,请阅读《IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token》。

[- 8 -] IM开发基础知识补课:正确理解前置HTTP SSO单点登录接口的原理

[链接] http://www.52im.net/thread-1351-1-1.html

[摘要] 针对上述主流移动IM系统中“长”、“短”连接的分工方式,其中最为重要也是用户最先接触到的——就是基于Http的SSO单点登陆接口(有的系统里可能并不叫SSO接口,本文讨论的是其广义:即实现身份认证功能的http接口),那么这个SSO接口工作原理是什么?可以怎么来实现?有无最佳实践建议?

[- -]  移动端IM中大规模群消息的推送如何保证效率、实时性?

[链接] http://www.52im.net/thread-1221-1-1.html

[摘要] 实际在生产环境下,群消息的发送都会想尽办法进行压缩,并开展各种改善性能的处理办法,而不是像上述举例里的直接扩散写(即2000人群里,一条消息被简单地复制为2000条一对一的消息投递)。具体有哪些优先策略?本文或许可以带给你一些启发。

[- 10 -] 移动端IM开发需要面对的技术问题

[链接] http://www.52im.net/thread-133-1-1.html

[摘要] 这两年多一直从事网易云信 iOS 端 IM SDK的开发,期间不断有兄弟部门的同事和合作伙伴过来问各种技术细节,干脆统一介绍下一个IM APP的方方面面,包括技术选型(包括通讯方式,网络连接方式,协议选择)和常见问题。

[- 11 -] 开发IM是自己设计协议用字节流好还是字符流好?

[链接] http://www.52im.net/thread-150-1-1.html

[摘要] 自己设计协议的话,协议用字节流好还是字符流好? 各有什么优缺点?

[- 12 -] 请问有人知道语音留言聊天的主流实现方式吗?

[链接] http://www.52im.net/thread-175-1-1.html

[摘要] 请问有人知道语音聊天的主流实现方式吗?就是类似微信那种,按住说话,录一段,发送那种。这语音文件录好之后是直接转成二进制发送。还是说当成一个文件上传到服务器,然后发送一个消息给对方,对方收到后下载?

[- 13 -] IM消息送达保证机制实现(一):保证在线实时消息的可靠投递

[链接] http://www.52im.net/thread-294-1-1.html

[摘要] 本文将要讨论的是即时IM应用中极其重要但也不被用户感知的消息送达保证机制(即QoS机制),文中将给出目前主流的参考实现思路。

[- 14 -] IM消息送达保证机制实现(二):保证离线消息的可靠投递

[链接] http://www.52im.net/thread-594-1-1.html

[摘要] 实时在线投递针对的是消息收发双方都在线的情况(如当发送方用户A发送消息给接收方用户B时,用户B是在线的),那如果消息的接收方用户B不在线,系统是如何保证消息的可达性的呢?这就是本文要讨论的问题。

[- 15 -] 如何保证IM实时消息的“时序性”与“一致性”?

[链接] http://www.52im.net/thread-714-1-1.html

[摘要] 实时消息时序和一致性是分布式系统架构设计中非常难的问题(尤其IM应用这种以消息为中心的应用形态),困难在哪?有什么常见优化实践?这就是本文要讨论的内容。

[- 16 -] 一个低成本确保IM消息时序的方法探讨

[链接] http://www.52im.net/thread-866-1-1.html

[摘要] IM类系统中,都需要考虑消息时序问题,如果后发送的消息先显示,可能严重扰乱聊天消息所要表达的意义。

[- 17 -] IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?

[链接] http://www.52im.net/thread-715-1-1.html

[摘要] “用户在线状态的一致性”(单聊好友在线状态、群聊用户在线状态)是IM应用领域比较难解决的一个技术问题,如何精准实时的获得好友、群友的在线状态,是今天将要探讨的话题。

[- 18 -] IM群聊消息如此复杂,如何保证不丢不重?

[链接] http://www.52im.net/thread-753-1-1.html

[摘要] 由于“消息风暴扩散系数”的存在(概念详见《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?》),群消息的复杂度要远高于一对一的单聊消息。群消息的实时性、可达性、离线消息是今天将要讨论的核心话题。

👉52im社区本周新文:《一套分布式IM即时通讯系统的技术选型和架构设计》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-12-21 10:30 Jack Jiang 阅读(49) | 评论 (0)编辑 收藏

本文由NetworkFox分享,来源于华三通信,原题“什么是国密算法?”,本文有修订和改动。

1、引言

最近几年经常能听到IM应用的开发者讨论国产信创方面的技术问题,在某些场景下,国密算法是硬性要求,所以学习一下国密算法还是很有必要的。

国密算法是指由中国国家密码管理局发布的密码算法标准,旨在保障国家信息安全。目前,国家密码管理局已发布了一系列国产商用密码标准算法,包括SM1(SCB2)、SM2、SM3、SM4、SM7、SM9以及祖冲之密码算法(ZUC)等。通过在金融、电子政务及安防等领域广泛应用国密算法,在对敏感数据进行机密性、完整性和可用性保护的同时,减少对外部密码产品的依赖,提升国家信息安全水平。

本文将尽量以通俗易懂的文字,为你分享国密算法的种类、技术原理和应用场景等。

 
 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4552-1-1.html

2、系列文章

本文是IM通讯安全知识系列文章中的第12篇,此系列总目录如下:

即时通讯安全篇(一):正确地理解和使用Android端加密算法

即时通讯安全篇(二):探讨组合加密算法在IM中的应用

即时通讯安全篇(三):常用加解密算法与通讯安全讲解

即时通讯安全篇(四):实例分析Android中密钥硬编码的风险

即时通讯安全篇(五):对称加密技术在Android平台上的应用实践

即时通讯安全篇(六):非对称加密技术的原理与应用实践

即时通讯安全篇(七):用JWT技术解决IM系统Socket长连接的身份认证痛点

即时通讯安全篇(八):如果这样来理解HTTPS原理,一篇就够了

即时通讯安全篇(九):你知道,HTTPS用的是对称加密还是非对称加密?

即时通讯安全篇(十):为什么要用HTTPS?深入浅出,探密短连接的安全性

即时通讯安全篇(十一):IM聊天系统安全手段之通信连接层加密技术

即时通讯安全篇(十二):IM聊天系统安全手段之传输内容端到端加密技术

即时通讯安全篇(十三):信创必学,一文读懂什么是国密算法》(* 本文)

3、为什么需要国密算法?

3.1国密算法的产生背景

在网络信息传输和存储过程中,数据的保密性和安全性是一项重要的需求。

传统的国际标准加密算法虽然安全可靠,但由于无法保证源代码的安全性,因此存在着源代码被外部恶意攻击者渗透或篡改的风险。为了构建安全的行业网络环境并增强国家行业信息系统的“安全可控”能力,中国积极开展了针对信息安全需求的研究和探索。

自2007年开始,中国制定了国密算法标准,并于2010年正式发布。

经过多年的发展、改进和完善,国密算法已成为中国自主研发的密码算法标准,并在各行业得到广泛应用。它的诞生不仅显著提升了中国在密码技术领域的核心竞争力,还为国家信息安全建设作出了重要贡献。

3.2国密算法的特点

国密算法具备如下特点:

1)安全性高:国密算法采用了严密的密码学原理和复杂的运算方式,具有较高的安全性。它在加密、数字签名和哈希等功能上都能提供可靠的保护,抵抗了各种传统和现代密码攻击手段。

2)高效性与灵活性:国密算法在保证安全性的同时,注重算法的效率。它的加密速度和运行效率相对较高,同时也能适应不同的密码长度和密钥长度,以满足不同场景的需求。

3)标准化广泛:国密算法已被国家标准化机构认可和采用。它符合国际密码学标准的基本要求,具备与国际算法相媲美的能力。同时,国密算法也在国内推广和应用广泛,成为中国信息安全领域的基础核心算法之一。

4)自主创新:国密算法是中国自主研发的密码算法,所以对于算法的实现和推广都具有独立的掌控能力。这意味着中国可以更好地保护自己的国家信息安全,减少对外依赖,提高自主抵抗能力。

5)面向多领域应用:国密算法不仅局限于某个特定领域的应用,它适用于金融业、电子商务、通信、物联网、区块链等不同领域的信息安全保护。它的广泛应用范围使得国密算法可以满足不同行业的安全需求。

4、国密算法应用概述

国密算法包括SM1(SCB2)、SM2、SM3、SM4、SM7、SM9以及祖冲之密码算法(ZUC)等。

其中:

  • 1)SM1、SM4、SM7、祖冲之密码(ZUC)属于对称算法;
  • 2)SM2、SM9属于非对称算法;
  • 3)SM3属于杂凑算法。

下文将主要介绍国密算法中的常用算法SM1、SM2、SM3和SM4的实现和应用。

5、SM1算法的原理和应用场景

SM1算法是国密算法中的一种对称加密算法,其特点是加解密使用相同密钥。利用SM1对称加密算法加解密数据的过程。

SM1算法未公开,仅以IP核(Intellectual Property Core,一种预先做好的集成电路功能模块)的形式存在于芯片中。

SM1算法主要用于小数据量的加密保护,因此被广泛用于研制智能IC卡、智能密码钥匙、门禁卡、加密卡等安全产品。

6、SM2算法的实现和应用场景

6.1概述

SM2算法是基于ECC(Elliptic Curve Cryptography)椭圆曲线的非对称加密算法,包括了SM2-1椭圆曲线数字签名算法、SM2-2椭圆曲线密钥交换协议和SM2-3椭圆曲线公钥加密算法,分别用于实现数字签名、密钥协商和数据加密等功能。

SM2算法在许多领域都有广泛的应用。

在电子商务领域:SM2算法被用于保护用户个人信息的安全传输,确保用户在网上交易过程中的隐私和财产的安全。

在互联网金融领域:SM2算法被用于数字支付、电子银行等场景,实现用户身份认证和交易的安全性。

此外,SM2算法还适用于物联网领域,保护物联网设备之间的通信安全,确保数据的可靠传输。

6.2数据加密

在非对称加密算法中,可对外公布的密钥称为“公钥”,只有持有者所知的密钥称为“私钥”。发送者使用接收者的公钥来加密消息,接收者用自己的私钥解密和读取该消息。

利用SM2非对称加密算法加解密数据的过程:

6.3密钥协商

由于椭圆曲线的计算复杂性高,破解难度大,因此SM2算法在密钥协商技术领域也起着关键作用。

利用SM2算法进行密钥协商的过程:

  • 1)会话双方生成自己的私钥(随机数);
  • 2)会话双方由私钥、ECC椭圆曲线参数G各自计算出公钥;
  • 3)会话双方将自己的公钥传递给对方,传递过程公开。由于椭圆曲线的计算复杂性高,破解难度大,因此攻击者难以通过公钥和椭圆曲线参数G反推出私钥;
  • 4) 双方将自己的私钥与对方的公钥进行运算,最终得到相同的会话密钥,该会话密钥可作为共享密钥用于对称加密(例如SM4算法)通信。

6.4数字签名

数字签名是一种用于验证信息完整性、真实性和来源的技术手段。它通常用于确保数据在传输或存储过程中没有被篡改,并且可以追溯到特定的发送方。

发送方使用自己的私钥对消息进行加密,生成数字签名。接收方使用发送方的公钥对签名进行解密和验证,以验证消息的完整性和真实性。

在数字签名应用中,SM2算法通常与SM3摘要算法一起使用。

7、SM3算法的实现和应用场景

SM3杂凑(Hashing)算法是国密算法中的一种摘要算法。

SM3算法通过哈希函数将任意长度的消息压缩成固定长度的摘要。摘要具有唯一性,即不同信息生成的摘要不同,且无法由摘要恢复出原始信息,更无法伪造信息获得相同摘要,因此SM3算法被广泛用于实现数字签名、数据完整性检测及消息验证等功能。

基于SM3算法的特点,在信息安全领域,SM3算法被用于保护密码学协议、数字证书和电子签名等数据的完整性。在区块链领域,SM3算法被用于加密货币的区块生成和链上交易的校验,确保区块链的安全性。

此外,SM3算法还可以应用于密码学随机数的生成和伪随机序列的校验等领域,增加了数据的安全性和可靠性。

利用SM2算法和SM3算法对用户数据进行数字签名认证及完整性校验的过程:

  • 1) 用户A发送的数据A经过SM3哈希算法运算生成摘要A。
  • 2) 摘要A经过用户A的私钥加密生成数字签名。
  • 3) 用户A的明文数据和数字签名经加密算法(SM1/SM2/SM4)加密成密文后发送给用户B。加密算法以非对称加密算法SM2为例,即加解密使用不同密钥。
  • 4)密文到达用户B处,经加密算法(SM1/SM2/SM4)解密后,还原成明文数据和数字签名。
  • 5)用户B使用用户A的公钥解密数据包中的数字签名:
  •      解密成功,数据来源合法,得到摘要A;
  •      解密失败,数据来源非用户A,丢弃本次数据。
  • 6)收到的数据包中的明文数据经过SM3哈希运算生成摘要A’。对比摘要A和摘要A’:
  •      摘要A’=摘要A,数据完整;
  •      摘要A’≠摘要A,数据被篡改,丢弃本次数据。

8、SM4算法的实现和应用

8.1概述

与SM1算法分类相同,SM4算法同样为分组对称加密算法,但SM4算法实现公开。

分组加密算法是将明文数据按固定长度进行分组,用同一密钥逐组加密,密文解密时同样使用相同密钥逐组解密。

SM4算法实现简单,因此加解密速度较快,消耗资源少,主要用于大数据量的加密和解密,例如静态储存或数据信号传输通道中数据的加解密。

在网络安全领域,SM4算法被用于保护网络传输和存储的敏感数据,如银行卡信息、密码等。在物联网领域,SM4算法被用于物联网设备之间的通信和数据加密,确保物联网数据的隐私安全。

此外,SM4算法还可以应用于区块链领域,保护加密货币的交易安全等领域,为相关系统和数据的安全提供了保障。

SM4算法支持ECB、CBC、CFB等多种分组模式,下文将介绍ECB和CBC两种基础模式。

8.2加解密模式:ECB模式

SM4算法基于ECB模式对数据加解密的过程:

  • 1)发送端将明文按固定长度分组,对每个明文分组分别使用相同的密钥进行加密生成密文分组。完整的密文由所有密文分组按序排列组合而成;
  • 2)接收端将密文按固定长度分组,对每个密文分组分别使用相同的密钥进行解密生成明文分组。所有明文分组按序排列组合而成完整的明文数据。

ECB模式实现简单,各段数据间互不影响,有利于并行运算,但相同的明文块会被加密成相同的密文块,不能提供严格的数据保密性。

8.3加解密模式:CBC模式

SM4算法基于CBC模式对明文加密的过程:

  • 1)将明文按固定长度分组;
  • 2)明文分组1与初始向量IV进行异或运算,异或运算的结果经密钥加密后得到密文分组1;
  • 3)剩余的明文分组依次与前一个密文分组进行异或运算后再加密,得到对应的密文分组;
  • 4)完整的密文由所有密文分组按序排列组合而成。

SM4算法基于CBC模式对密文解密的过程:

  • 1)将密文按固定长度分组后,对密文分组进行倒序处理;
  • 2)对密文分组n先使用密钥进行解密,密文分组n解密后的数据与密文分组n-1进行逻辑逆运算,得到明文分组n;
  • 3) 同理,剩余的密文分组解密后再与前一个密文分组进行逻辑逆运算,得到对应的明文分组;
  • 4)最后,密文分组1用密钥解密后的数据是与初始向量进行逻辑逆运算,然后得到明文分组1;
  • 5)完整的明文由所有明文分组按序排列组合而成。

CBC模式安全性高于ECB,但明文块不能并行计算,且误差会传递下去。

9、国密算法与国际标准算法的对比

国密算法和国际标准算法都是现代密码学中常用的加密算法,但在技术和优劣方面存在一些区别。

常见国密算法与国际标准算法各参数性能的对比如下:

 

10、国密算法的典型应用场景有哪些?

10.1AD-WAN纵向IP/MPLS组网

国密算法可以与AD-WAN技术结合,应用于IP/MPLS纵向网场景。

通过AD-WAN智能运维平台,实现国密配置一键下发,在网络中构建国密数据加密通道,实现基于国密的端到端的IPsec隧道保护。

国密算法在端到端的IPsec隧道中的工作原理如下:

1)在IKE密钥协商阶段,使用IKE协议进行密钥协商过程中,采用SM2算法生成会话密钥。

2)在身份认证阶段,本端使用SM2和SM3算法生成身份信息的数字签名,并使用SM1或SM4算法和会话密钥对身份信息和数字签名进行加密;对端收到加密的身份信息后,使用相同的会话密钥解密,然后通过SM2和SM3算法进行身份认证。

3)在数据传输阶段,本端使用SM2和SM3算法生成用户数据的数字签名,并使用SM1或SM4算法以及会话密钥对用户数据和数字签名进行加密;对端收到加密的用户数据后,使用相同的会话密钥解密,然后通过SM2和SM3算法进行数据完整性检查。

10.24G/5G VPDN业务组网

4G/5G VPDN(Virtual Private Dialup Network,虚拟专有拨号网络)业务是在4G/5G无线网络中采用拨号方式实现的一种虚拟专有网络业务。它利用L2TP技术为客户构建与互联网隔离的隧道,以满足客户分支和总部内网通信的需求。VPDN组网同时支持将L2TP和IPsec技术结合,通过L2TP完成用户认证确保接入安全,并利用IPsec保障通信数据安全。

1)4G/5G VPDN组网中分支网关由4G/5G路由设备担任,通过拨号接入运营商网络。

2)运营商对4G/5G路由设备的APN(Access Point Name,接入点名称)、账户、SIM/USIM卡信息进行认证。

3)4G/5G路由设备认证通过后被运营商判断是VPDN用户,同时由运营商AAA服务器向LAC(L2TP Access Concentrator,L2TP访问集中器)设备下发L2TP隧道属性,LAC设备将基于下发的L2TP隧道属性信息向该VPDN用户所属总部的LNS(L2TP Network Server,L2TP网络服务器)设备发起隧道建立请求。

4)L2TP隧道建立后,LAC设备会通过此隧道向LNS设备透传用户的认证信息。LNS设备向总部内网的AAA服务器发起对VPDN用户的二次认证,认证通过后为VPDN用户分配一个企业内网IP地址。分支终端用户和总部可以开始通信。

5)分支网关与总部网关设备上均安装有国密板卡,通过IPsec协商建立起端到端的IPsec隧道,使用国密算法对传输的数据报文进行加密保护和数据完整性检查。

6)经IPsec加密后的数据报文在LAC设备处进行L2TP封装后,通过L2TP隧道传输到LNS。

7)LNS收到数据报文后首先对L2TP报文进行解封装,然后经过IPsec解密还原出数据报文,根据报文目的IP地址转发报文。

11、相关文章

[1] 常用加解密算法与通讯安全讲解

[2] 非对称加密技术的原理与应用实践

[3] IM聊天系统安全手段之通信连接层加密技术

[4] IM聊天系统安全手段之传输内容端到端加密技术

[5] 通俗易懂:一篇掌握即时通讯的消息传输安全原理

[6] 基于Netty的IM聊天加密技术学习:一文理清常见的加密概念、术语等

[7] 理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)

[8] 微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解

[9] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书


(本文已同步发布于:http://www.52im.net/thread-4552-1-1.html

posted @ 2023-12-14 11:06 Jack Jiang 阅读(57) | 评论 (0)编辑 收藏

​为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第27 期。

[- 1 -] 专访微信视频技术负责人:微信实时视频聊天技术的演进

[链接] http://www.52im.net/thread-1201-1-1.html

[摘要] 本次专访是对谷沉沉老师在即将到来的 2017ArchSummit 全球架构师峰会上,以《数亿微信视频通话背后的视频技术二三事》为题发表演讲的一次预热。


[- 2 -] 腾讯音视频实验室:使用AI黑科技实现超低码率的高清实时视频聊天

[链接] http://www.52im.net/thread-1308-1-1.html

[摘要] 腾讯音视频实验室和优图实验室X-lab的戴宇榮老师的团队联合开发的基于神经网络的实时视频超分辨率技术,在极小的神经网络模型大小的条件下,在手机实时视频通话上实现了基于机器学习的超分辨率技术,起到了主观上提升一档分辨率的效果。此技术即将应用在手机QQ 7.3.5的iOS版本上的实时视频聊天。


[- 3 -] 微信团队分享:微信每日亿次实时音视频聊天背后的技术解密

[链接] http://www.52im.net/thread-1311-1-1.html

[摘要] 本文将为大家介绍微信实时音视频聊天在不同发展阶段的各个关键视频技术环节采用的方案,同时分享在实时音视频聊天中的视频编码器研发的方法和经验。


[- 4 -]福利贴:最全实时音视频开发要用到的开源工程汇总

[链接] http://www.52im.net/thread-1395-1-1.html

[摘要] 本文汇总了一些能帮助到正在学习或进行实时音视频开发的同行们的开源工程,这些工程分为几类:音视频编解码类、视频前后处理、服务端类等,希望能加速您的学习或研究过程。


[- 5 -] 实时音视频聊天中超低延迟架构的思考与技术实践

[链接] http://www.52im.net/thread-1465-1-1.html

[摘要] 从直播在线上抓娃娃,不断变化的是玩法的创新,始终不变的是对超低延迟的苛求。实时架构是超低延迟的基石,如何在信源编码、信道编码和实时传输整个链条来构建实时架构?在实时架构的基础之上,如果通过优化采集、编码、传输、解码和渲染中的关键环节来降低延迟?本文将会介绍即构在这方面的思考与实践。


[- 6 -] 理解实时音视频聊天中的延时问题一篇就够

[链接] http://www.52im.net/thread-1553-1-1.html

[摘要] 音视频实时通讯的应用场景已经随处可见,从“吃鸡”的语音对讲、直播连麦、直播答题组队开黑,再到银行视频开户等。对于开发者来讲,除了关注如何能快速实现不同应用场景重点额音视频通讯,另一个更需要关注的可能就是“低延时”。但是,到底实时音视频传输延时应该如何“低”,才能满足你的应用场景呢?


[- 7 -] 写给小白的实时音视频技术入门提纲

[链接] http://www.52im.net/thread-1620-1-1.html

[摘要] 本文是由一篇演讲稿整理出来的文章,目标读者是对实时音视频开发感兴趣但是又不知道如何下手的初学者们,对大家有所帮助。


[- 8 -] 微信多媒体团队访谈:音视频开发的学习、微信的音视频技术和挑战等

[链接] http://www.52im.net/thread-1746-1-1.html

[摘要] 腾讯多媒体内核中心高级研究员时永方接受了LiveVideoStack的邮件采访,谈及了个人成长中的关键时刻,学习多媒体开发的三点核心,以及在5G和高清时代下,微信多媒体团队面临的挑战。


[- 9 -]  腾讯技术分享:微信小程序音视频技术背后的故事

[链接] http://www.52im.net/thread-1799-1-1.html

[摘要] 本文来自腾讯视频云终端技术总监rexchang(常青)的技术分享,讲述的是微信小程序中音视频技术构思、设计和实现等方方面的内容,希望能为你的音视频技术实践带来启发。


[- 10 -] 微信多媒体团队梁俊斌访谈:聊一聊我所了解的音视频技术

[链接] http://www.52im.net/thread-1828-1-1.html

[摘要] 从华为2012实验室到腾讯,过去十余年梁俊斌一直专注在音频技术。他告诉LiveVideoStack:音频技术还有许多难点需要解决,而作为技术人也延展到应用场景,关注用户需求。本文整理了本次访谈的主要内容,仅供参阅。


[- 11 -] 新浪微博技术分享:微博短视频服务的优化实践之路

[链接] http://www.52im.net/thread-1843-1-1.html

[摘要] 本文的短视频技术跟IM的单聊、群聊、朋友圈里的小视频是类似的东西,文中针对短视频的相关优化实践可以为您的IM小视频开发提供一定的参考和借鉴意义,希望对您有用。


[- 12 -] 以网游服务端的网络接入层设计为例,理解实时通信的技术挑战

[链接] http://www.52im.net/thread-1915-1-1.html

[摘要] 本文将尝试从开发者角度:梳理开发网游服务端的网络接入层的过程中面临的各种技术挑战,并针对性地提供相应的实时通信网络接入层解决思路,希望对于即时通讯应用的开发者来说,可以从中得到些许启发。


[- 13 -] 腾讯技术分享:微信小程序音视频与WebRTC互通的技术思路和实践

[链接] http://www.52im.net/thread-1988-1-1.html

[摘要] 本文来自腾讯视频云终端技术总监rexchang(常青)技术分享,内容分别介绍了微信小程序视音视频和WebRTC的技术特征、差异等,并针对两者的技术差异分享和总结了微信小程序视音视频和WebRTC互通的实现思路以及技术方案。希望能带给你启发。


[- 14 -] 爱奇艺技术分享:轻松诙谐,讲解视频编解码技术的过去、现在和将来

[链接] http://www.52im.net/thread-3028-1-1.html

[摘要] 本文以轻松幽默的语气,讲解了视频编解码的一些基本常识,并以爱奇艺为例,讲述了视频编解码技术在国内的发展以及未来的一些展望。


[- 15 -] 零基础入门:实时音视频技术基础知识全面盘点

[链接] http://www.52im.net/thread-3079-1-1.html

[摘要] 本文是作者自已根据入门实时音视频的亲身经历,对于基础知识点的认知总结。虽然很浅显,但相对小白来说,能稍微系统的了解这些概念就已经是很好的起点了。


[- 16 -] 实时音视频面视必备:快速掌握11个视频技术相关的基础概念

[链接] http://www.52im.net/thread-3194-1-1.html

[摘要] 本文将通过通俗的文字,言简意赅地为你讲解实时音视频技术中跟视频技术在关的11个非常重要的基础知识概念,希望能为你日后从事这方面的工作起到抛砖引玉的作用。


[- 17 -] 实时音视频开发理论必备:如何省流量?视频高度压缩背后的预测技术

[链接] http://www.52im.net/thread-3581-1-1.html

[摘要] 本文将从视频编解码技术的基础知识入手,引出视频编解码技术中非常基础且重要的预测技术,学习帧内预测和帧间预测的技术原理。


👉52im社区本周新文:《即时通讯安全篇(十三):信创必学,一文读懂什么是国密算法》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-12-13 11:57 Jack Jiang 阅读(62) | 评论 (0)编辑 收藏

一、关于RainbowChat-Web

RainbowChat-Web是一套Web网页端IM系统,是RainbowChat的姊妹系统(RainbowChat是一套基于开源IM聊天框架 MobileIMSDK (Github地址)  的产品级移动端IM系统)。

二、v6.0 版更新内容

此版更新内容更多历史更新日志):

  • 1)[bug][服务端] - 解决了群成员从首页“消息”列表中删除已解散群的item时没有反应的问题;
  • 2)[新增][服务端] - 安全提升,实现了一套新的token生成、校验机制(支持对称加密和非对称加密两种模式);
  • 3)[新增][服务端] - 安全提升,启用了AppKey校验机制;
  • 4)[新增][前端]    - 优化了http接口、文件上传接口校验逻辑,提升安全性;
  • 5)[新增][前端]    - 安全提升,启用了AppKey校验机制;
  • 6)[新增][前端]    - 新增发送“群名片”消息功能;
  • 7)[新增][前端]    - 新增了消息转发功能;
  • 8)[优化][前端]    - 其它细节优化等。

三、v6.0 版新增特性截图

“群名片”功能运行截图查看演示视频更多运行截图):

“消息转发”功能(查看演示视频更多运行截图):

posted @ 2023-12-11 12:08 Jack Jiang 阅读(44) | 评论 (0)编辑 收藏

     摘要: 本文由字节跳动技术团队高原、汤中峰分享,原题“抖音功耗优化实践”,本文有修订和改动。一、引言功耗优化是应用体验优化的一个重要课题,高功耗会引发用户的电量焦虑,也会导致糟糕的发热体验,从而降低了用户的使用意愿。而功耗又是涉及整机的长时间多场景的综合性复杂指标,影响因素很多。不论是功耗的量化拆解,还是异常问题的监控,以及主动的功耗优化对于开发人员来说都是很有挑战性的。本文结合抖...  阅读全文

posted @ 2023-12-07 11:37 Jack Jiang 阅读(106) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第26 期。

[- 1 -] 实时语音聊天中的音频处理与编码压缩技术简述

[链接] http://www.52im.net/thread-825-1-1.html

[摘要] 在视频或者音频通话过程中,一方面为了减小原始声音数据的传输码率,需要进行音频压缩,另一方面为了得到更高质量的音质,需要进行音频处理。如何处理好这两方面,保证声音传播的高真性,是个技术活儿!

[- 2 -] 网易视频云技术分享:音频处理与压缩技术快速入门

[链接] http://www.52im.net/thread-678-1-1.html

[摘要] 随着音频处理和压缩技术的不断发展,效果更好、适用范围更广、性能更高的算法和新的技术必将不断涌现,不断改善我们的生活。

[- 3 -] 学习RFC3550:RTP/RTCP实时传输协议基础知识

[链接] http://www.52im.net/thread-590-1-1.html

[摘要] 本文对这些协议进行初步归纳总结,在分析RFC3550的基础上,重点分析RTP系列协议,并以报文类型为主线分析RTCP系列协议。

[- 4 -]基于RTMP数据传输协议的实时流媒体技术研究(论文全文)

[链接] http://www.52im.net/thread-273-1-1.html

[摘要] 本文来自论文《基于 RTMP 协议的流媒体技术的原理与应用》,文中研究了基于 Flash 平台的流媒体系统中使用的 RTMP 协议的原理和应用,并对网络上实时流媒体的各种传输方式的优缺点进行了分析。

[- 5 -] 声网架构师谈实时音视频云的实现难点(视频采访)

[链接] http://www.52im.net/thread-399-1-1.html

[摘要] 孙雨润,声网 Agora.io 首席音视频架构师,负责全球音视频传输技术架构。毕业于中国科学技术大学,原 YY 后台架构师,主导 Web YY 整体后台系统架构搭建。曾任职腾讯 QQ 研究员 ,主导 QQ 空间面孔墙等项目;任职微软 Microsoft 期间,参与高性能计算产品项目。

[- 6 -] 还在靠“喂喂喂”测试实时语音通话质量?本文教你科学的评测方法!

[链接] http://www.52im.net/thread-507-1-1.html

[摘要] 实时语音聊天开发,对于一般的开发者来说比较神秘,很多朋友不太清楚如何全面的评估一个音频引擎。

[- 7 -] 如何用最简单的方法测试你的实时音视频方案

[链接] http://www.52im.net/thread-535-1-1.html

[摘要] 本文总结了一些有关实时音视频方案比较值得自测的要点,旨在没有生产环境反馈和丰富的测试资源情况下,用较低的成本来测试覆盖尽可能多的真实场景中可能遇到的网络和设备问题。

[- 8 -] 简述实时音视频聊天中端到端加密(E2EE)的工作原理

[链接] http://www.52im.net/thread-763-1-1.html

[摘要] 本文着重阐述端到端加密(E2EE),端到端加密是确保数据传输安全的可行方法之一。读完这篇文章,你可以了解这种加密方式的基本原理.

[- -]  理论联系实际:实现一个简单地基于HTML5的实时视频直播

[链接] http://www.52im.net/thread-875-1-1.html

[摘要] 本次分享就向大家介绍一下分享一下直播的整个流程和一些技术点,并动手实现一个简单的Demo。

[- 10 -] IM实时音视频聊天时的回声消除技术详解

[链接] http://www.52im.net/thread-939-1-1.html

[摘要] 为了不让文章读起来枯燥,本文将尽量通俗易懂地为您讲解实时音视频聊天场景下的回声消除技术原因希望能带给你些许启发。

[- 11 -] 如何优化传输机制来实现实时音视频的超低延迟?

[链接] http://www.52im.net/thread-1008-1-1.html

[摘要] 要在语音视频 SDK 中实现超低延迟,实时的语音视频传输机制是必不可少的,而 FEC 和 ARQ 的智能结合是实时语音视频传输机制的基石。

[- 12 -] 实时通信RTC技术栈之:视频编解码

[链接] http://www.52im.net/thread-1034-1-1.html

[摘要] 本文是系列文章的第一篇:讲述视频编解码的一些基本知识。

[- 13 -] Android直播入门实践:动手搭建一套简单的直播系统

[链接] http://www.52im.net/thread-1154-1-1.html

[摘要] 实时视频直播是这两年非常火的技术形态,已经渗透到教育、在线互娱等各种业务场景中。但要搭建一套实时视频直播系统,并非易事,当然相关的直播技术理论在论坛的其它文章里已经写的非常详细,本文不再展开。

[- 14 -] 网易云信实时视频直播在TCP数据传输层的一些优化思路

[链接] http://www.52im.net/thread-1254-1-1.html

[摘要] 网易云信的实时视频直播目前使用了TCP进行传输,且基于此,从编码动态适配、发送队列调整、协议优化、socket等做了全流程的优化,确保在限带宽、丢包、时延、抖动,无论单项还是复杂网络,都有非常不错的实际体验。

[- 15 -] 实时音视频聊天技术分享:面向不可靠网络的抗丢包编解码器

[链接] http://www.52im.net/thread-1281-1-1.html

[摘要] 编解码器面向直播和网络通信是不一样的,我今天想说的是面向不可靠传输网络的抗丢包编解码器。

[- 16 -] P2P技术如何将实时视频直播带宽降低75%?

[链接] http://www.52im.net/thread-1289-1-1.html

[摘要] 那整个系统是怎么设计的?使用了哪些技术来达成目标?接下来我来重点分享一下架构设计和技术细节。

👉52im社区本周新文:《抖音技术分享:抖音Android端手机功耗问题的全面分析和详细优化实践》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-12-06 12:22 Jack Jiang 阅读(62) | 评论 (0)编辑 收藏

     摘要: 本文由竹子爱熊猫分享,原题“(十一)Netty实战篇:基于Netty框架打造一款高性能的IM即时通讯程序”,本文有修订和改动。1、引言关于Netty网络框架的内容,前面已经讲了两个章节,但总归来说难以真正掌握,毕竟只是对其中一个个组件进行讲解,很难让诸位将其串起来形成一条线,所以本章中则会结合实战案例,对Netty进行更深层次的学习与掌握,实战案例也并不难,一个非常朴素的I...  阅读全文

posted @ 2023-11-30 12:28 Jack Jiang 阅读(57) | 评论 (0)编辑 收藏

​为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第25 期。

[- 1 -] 即时通讯音视频开发(一):视频编解码之理论概述

[链接] http://www.52im.net/thread-228-1-1.html

[摘要] 本文主要讲解实时音视频技术中视频技术的编解码基础理论。

[- 2 -] 即时通讯音视频开发(二):视频编解码之数字视频介绍

[链接] http://www.52im.net/thread-229-1-1.html

[摘要] 本文主要讲解实时音视频技术中视频技术的数字视频知识。

[- 3 -] 即时通讯音视频开发(三):视频编解码之编码基础

[链接] http://www.52im.net/thread-232-1-1.html

[摘要] 本文主要讲解实时音视频技术中视频技术的编码理论知识。

[- 4 -] 即时通讯音视频开发(四):视频编解码之预测技术介绍

[链接] http://www.52im.net/thread-235-1-1.html

[摘要] 本文主要讲解实时音视频技术中视频技术的预测技术理论知识。

[- 5 -] 即时通讯音视频开发(五):认识主流视频编码技术H.264

[链接] http://www.52im.net/thread-237-1-1.html

[摘要] 本文主要讲解实时音视频技术中目前主流的视频编码技术H.264相关知识。

[- 6 -] 即时通讯音视频开发(六):如何开始音频编解码技术的学习

[链接] http://www.52im.net/thread-241-1-1.html

[摘要] 本文是一篇讲述新手如何学习音频编解码知识的文章。

[- 7 -] 即时通讯音视频开发(七):音频基础及编码原理入门

[链接] http://www.52im.net/thread-242-1-1.html

[摘要] 本文是一篇讲述基础音频知识和编码原理的文章。

[- 8 -]  即时通讯音视频开发(八):常见的实时语音通讯编码标准

[链接] http://www.52im.net/thread-243-1-1.html

[摘要] 本文是一篇讲述常用的实用音频通讯编码标准的文章。

[- 9 -] 即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述

[链接] http://www.52im.net/thread-247-1-1.html

[摘要] 本文是一篇介绍实时音频通讯过程中的回音问题,以及回音消除技术的介绍文章。

[- 10 -] 即时通讯音视频开发(十):实时语音通讯的回音消除技术详解

[链接] http://www.52im.net/thread-250-1-1.html

[摘要] 本文是一篇详细介绍实时音频通讯过程中的回音消除技术的文章,主要描述的是回音消除技术理论和算法原理等。

[- 11 -] 即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解

[链接] http://www.52im.net/thread-251-1-1.html

[摘要] 本文是一篇详细介绍实时语音通讯过程中的丢包补偿技术的文章。

[- 12 -] 即时通讯音视频开发(十二):多人实时音视频聊天架构探讨

[链接] http://www.52im.net/thread-253-1-1.html

[摘要] 虽然都是视频通讯,大部分情况下的单人视频通话可能根本不需要用到流媒体服务,而多人视频,如在线教育这些则必须用到,所以下面主要介绍多人视频中服务端架构模式,以及各自特点。

[- 13 -] 即时通讯音视频开发(十三):实时视频编码H.264的特点与优势

[链接] http://www.52im.net/thread-266-1-1.html

[摘要] 本文主要讲解实时音视频技术中最流行的视频编码技术H.264的特点和优势,希望能为您的技术选型提供一定的参考。

[- 14 -] 即时通讯音视频开发(十四):实时音视频数据传输协议介绍

[链接] http://www.52im.net/thread-267-1-1.html

[摘要] 本文将简要介绍这些主流的实时音视频数据传输协议。

[- 15 -] 即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况

[链接] http://www.52im.net/thread-269-1-1.html

[摘要] p2p就是点对点,两个客户端直接进行数据交互,不需要经过服务器转发(relay),这种方式能大大减轻服务端的负载,所以特别视适合大数据的传输,比如实时音视频聊天、在线视频直播、大文件传输等应用场景。

[- 16 -] 即时通讯音视频开发(十六):移动端实时音视频开发的几个建议

[链接] http://www.52im.net/thread-270-1-1.html

[摘要] 本文将就几个典型问题给出简要的参考建议。

[- 17 -] 即时通讯音视频开发(十七):视频编码H.264、VP8的前世今生

[链接] http://www.52im.net/thread-274-1-1.html

[摘要] 本文重在为读者从技术角度讲解H.264和VP8的发展渊源以及现时所面临的问题,相信读完此文后,对于即时通讯(IM聊天应用)的实时音视频开发中视频编码的选择会有个直观的了解。

[- 18 -] 即时通讯音视频开发(十八):详解音频编解码的原理、演进和应用选型

[链接] http://www.52im.net/thread-2230-1-1.html

[摘要] 以下就是本次为大家分享的主要内容,希望通过此次分享可以使大家对音频编解码有一个整体的认识,并在实际应用中有参考的依据。

[- 19 -] 即时通讯音视频开发(十九):零基础,史上最通俗视频编码技术入门

[链接] http://www.52im.net/thread-2840-1-1.html

[摘要] 视频编码技术涉及的内容太过专业和庞杂,市面上的书籍或博客多数都只是枯燥的技术概念罗列,对于新手来说读完依旧蒙逼是常态,本文将借此机会,专门给大家做一个关于视频编码的零基础科普。

[- 20 -] 即时通讯音视频开发(二十):一文读懂视频的颜色模型转换和色域转换

[链接] http://www.52im.net/thread-4467-1-1.html

[摘要] 本文将以通俗易懂的文字,引导你理解视频是如何从采集开始,历经各种步骤,最终通过颜色模型转换和不同的色域转换,让你看到赏心悦目的视频结果的。

👉52im社区本周新文:《跟着源码学IM(十二):基于Netty打造一款高性能的IM即时通讯程序》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-11-29 13:41 Jack Jiang 阅读(51) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第 24 期。

[- 1 -] 开源实时音视频技术WebRTC的现状

[链接] http://www.52im.net/article-126-1.html

[摘要] 作为Google开源的技术,WebRTC并不是一个可以拿来就用并且性能很好的产品,而且正如众多的其它开源技术一样,WebRTC的发展并没有期待中的快。


[- 2 -] 简述开源实时音视频技术WebRTC的优缺点

[链接] http://www.52im.net/thread-225-1-1.html

[摘要] 作为Google开源的技术,WebRTC并不是一个可以拿来就用并且性能很好的产品,需要工程师们对其进行较多的改善。本文主要来谈一谈WebRTC的优缺点。


[- 3 -] 访谈WebRTC标准之父:WebRTC的过去、现在和未来

[链接] http://www.52im.net/thread-227-1-1.html

[摘要] 首届(WebRTC)网络实时通信大会期间,InfoQ 对 WebRTC 之父 Daniel C. Burnett 进行了专访,以下是专访实录。(注:Daniel 在访谈中的观点仅代表他本人及其在 W3C 所做的工作。)


[- 4 -] 良心分享:WebRTC 零基础开发者教程(中文)[附件下载]

[链接] http://www.52im.net/thread-265-1-1.html

[摘要] WebRTC,名称源自网页实时通信(Web Real-Time Communication)的缩写,是一个支持网页浏览器进行实时语音通话或视频聊天的技术,是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术。


[- 5 -] WebRTC实时音视频技术的整体架构介绍

[链接] http://www.52im.net/thread-284-1-1.html

[摘要] 虽然WebRTC的目标是实现跨平台的Web端实时音视频通讯,但因为核心层代码的Native、高品质和内聚性,开发者很容易进行除Web平台外的移殖和应用。很长一段时间内WebRTC是业界能免费得到的唯一高品质实时音视频通讯技术。


[- 6 -] 新手入门:到底什么是WebRTC服务器,以及它是如何联接通话的?

[链接] http://www.52im.net/thread-356-1-1.html

[摘要] 通过WebRTC的端到端通信通常被人们所误解。WebRTC并不是真正意味着你不需要服务器来协商和联接通话。它只意味着,在多数情况中,你可以直接地在浏览器之间进行通信。


[- 7 -] WebRTC实时音视频技术基础:基本架构和协议栈

[链接] http://www.52im.net/thread-442-1-1.html

[摘要] 本文主要介绍WebRTC的架构和协议栈。


[- 8 -]  浅谈开发实时视频直播平台的技术要点

[链接] http://www.52im.net/thread-475-1-1.html

[摘要] 现在大大小小的公司,甚至个人开发者,都想开发自己的直播网站或App,本文会帮你理清,开发视频直播平台,你需要注意哪些技术要点。


[- 9 -] [观点] WebRTC应该选择H.264视频编码的四大理由

[链接] http://www.52im.net/thread-488-1-1.html

[摘要] 对实时音视频开发者来说,当开发一个基于WebRTC的产品时,我们应该选择什么样的视频编解码器?去年的时候,答案可能是“VP8”。几个月前,答案可能是“看情况”。现在答案是“除非必须用VP8,否则就用H.264”。


[- 10 -] 基于开源WebRTC开发实时音视频靠谱吗?第3方SDK有哪些?

[链接] http://www.52im.net/thread-510-1-1.html

[摘要] 利用Google开源的WebRTC来开发自已的实时音视频系统,靠不靠谱这个问题一直被问到,其实很难一两句话说清楚,因为答案不是一个靠谱或不靠谱可以回答好的,既然被反复问到,今天就系统地整理参考答案。


[- 11 -] 开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用

[链接] http://www.52im.net/thread-589-1-1.html

[摘要] 本文在深入研究WebRTC源代码的基础上,以Video数据的发送和接收为例,力求用简洁语言描述RTP/RTCP模块的实现细节,为进一步深入掌握WebRTC打下良好基础。


[- 12 -] 简述实时音视频聊天中端到端加密(E2EE)的工作原理

[链接] http://www.52im.net/thread-763-1-1.html

[摘要] 本文着重阐述端到端加密(E2EE),端到端加密是确保数据传输安全的可行方法之一。读完这篇文章,你可以了解这种加密方式的基本原理.


[- 13 -] 实时通信RTC技术栈之:视频编解码

[链接] http://www.52im.net/thread-1034-1-1.html

[摘要] 那么 RTC 技术栈究竟包含哪些技术,我们会提供一系列文章,来解读 RTC 技术栈。本文是系列文章的第一篇:讲述视频编解码的一些基本知识。


[- 14 -] 开源实时音视频技术WebRTC在Windows下的简明编译教程

[链接] http://www.52im.net/thread-1125-1-1.html

[摘要] WebRTC是提供了一整套处理实时音视频的开源库。它包括了音视频处理(采集,编解码,前处理,后处理,渲染),数据传输(实时传输,流控)和业务逻辑控制。可以说 WebRTC 的出现大大减少了做音视频开发的难度,所以熟练掌握好这个库对于做音视频相关的同学就显的特别重要了。


[- 15 -] 网页端实时音视频技术WebRTC:看起来很美,但离生产应用还有多少坑要填?

[链接] http://www.52im.net/thread-1282-1-1.html

[摘要] 直到2011年,WebRTC技术的出现,并且由谷歌做推广。WebRTC带来的体验是因为免安装才受到了关注。


[- 16 -] 了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化

[链接] http://www.52im.net/thread-1631-1-1.html

[摘要] 有人说 2017 年是 WebRTC 的转折之年,2018 年将是 WebRTC 的爆发之年,这并非没有根据。就在去年(2017年),WebRTC 1.0 标准草案出炉(实际上WebRTC标准草案的早期版本早在2011年就已经发布,WebRTC并非一夜之间就出现的技术),并将于今年正式发布。与此同时,越来越多的浏览器和厂商都开始对它进行广泛的支持,WebRTC 即将成为互联网的基础设施了,或许门槛如此之高的实时音视频技术终有白菜化的那一天。


[- 17 -] 腾讯技术分享:微信小程序音视频与WebRTC互通的技术思路和实践

[链接] http://www.52im.net/thread-1988-1-1.html

[摘要] 本文来自腾讯视频云终端技术总监rexchang(常青)技术分享,内容分别介绍了微信小程序视音视频和WebRTC的技术特征、差异等,并针对两者的技术差异分享和总结了微信小程序视音视频和WebRTC互通的实现思路以及技术方案。希望能带给你启发。


[- 18 -] 融云技术分享:基于WebRTC的实时音视频首帧显示时间优化实践

[链接] http://www.52im.net/thread-3169-1-1.html

[摘要] 本文主要通过对WebRTC接收端的音视频处理过程分析,来了解和优化视频首帧的显示时间,并进行了总结和分享。


[- 19 -] 零基础入门:基于开源WebRTC,从0到1实现实时音视频聊天功能

[链接] http://www.52im.net/thread-3680-1-1.html

[摘要] 本文将基于笔者公司开发的在线问诊产品中WebRTC技术的实践经验,讲述的如何基于WebRTC从零开发一个实时音视频聊天功能。文章会从WebRTC的基本知识、技术原理开始,基于开源技术为你演示如何搭建一个WebRTC实时音视频聊天功能。


[- 20 -] 实时音视频入门学习:开源工程WebRTC的技术原理和使用浅析

[链接] http://www.52im.net/thread-3804-1-1.html

[摘要] WebRTC(全称 Web Real-Time Communication),即网页即时通信。是一个支持网页浏览器进行实时语音对话或视频对话的技术方案。从前端技术开发的视角来看,是一组可调用的API标准。


👉52im社区本周新文:《哔哩哔哩从0到1自研智能客服IM系统的技术实践之路 http://www.52im.net/thread-4517-1-1.html》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-11-24 11:39 Jack Jiang 阅读(57) | 评论 (0)编辑 收藏

     摘要: 本文由B端技术中心分享,原题“从0到1:哔哩哔哩智能客服系统的设计与实现”,本文有修订和改动。1、引言本文将要分享的是哔哩哔哩从0到1自研智能客服IM系统的技术实践过程,包括整体架构设计和主要核心功能的技术实现思路等,希望带给你启发。* 推荐阅读:《得物从0到1自研客服IM系统的技术实践之路》。  技术交流:- 移动端IM开发入门文章:《新手入门一篇就够...  阅读全文

posted @ 2023-11-23 11:53 Jack Jiang 阅读(71) | 评论 (0)编辑 收藏

     摘要: 本文由微信客户端团队rhythm分享,原题“视频号直播:如何进一步降低功耗占用?”,本文有修订和改动。1、引言功耗优化一直是 app 性能优化中让人头疼的问题,尤其是在直播这种用户观看时长特别久的场景。怎样能在不影响主体验的前提下,进一步优化微信iOS端视频号直播的功耗占用,本文给出了一个不太一样的答案。  技术交流:- 移动端IM开发入门文章:《新手入...  阅读全文

posted @ 2023-11-16 11:57 Jack Jiang 阅读(52) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第23 期。

[- 1 -] 理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)

[链接] http://www.52im.net/thread-283-1-1.html

[摘要] 本文将以理论联系实际的方式,详细讲解一套典型IM的通信协议设计的方方面面。


[- 2 -] 微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解

[链接] http://www.52im.net/thread-310-1-1.html

[摘要] 通信安全是互联网应用首要考虑的问题,有别于传统PC应用,随着移动互联网时代的到来,移动端的通信安全性要同时权衡:安全、性能、体验、数据流量等等方面,要实现一个完整而实用的通信安全解决方案并非易事。本文将详细介绍基于TLS 1.3的微信新一代通信安全协议mmtls。


[- 3 -] 来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享

[链接] http://www.52im.net/thread-215-1-1.html

[摘要] OpenIM是阿里巴巴推出的,集成于阿里百川项目中的移动端IM开放服务。阿里百川是阿里巴巴集团无线开放平台,为移动开发者(涵盖移动创业者)提供快速搭建APP、加速APP商业化、提升用户体验的解决方案。


[- 4 -]简述实时音视频聊天中端到端加密

[链接] http://www.52im.net/thread-763-1-1.html

[摘要] 本文着重阐述端到端加密(E2EE),端到端加密是确保数据传输安全的可行方法之一。读完这篇文章,你可以了解这种加密方式的基本原理.


[- 5 -] 移动端安全通信的利器——端到端加密(E2EE)技术详解

[链接] http://www.52im.net/thread-764-1-1.html

[摘要] 端到端加密允许数据在从源点到终点的传输过程中始终以密文形式存在。采用端到端加密(又称脱线加密或包加密)时消息在被传输时到达终点之前不进行解密,因为消息在整个传输过程中均受到保护,所以即使有节点被损坏也不会使消息泄露。


[- 6 -] Web端即时通讯安全:跨站点WebSocket劫持漏洞详解(含示例代码)

[链接] http://www.52im.net/thread-793-1-1.html

[摘要] 本文将深入浅出为读者介绍跨站点 WebSocket 漏洞的原理、检测方法和修复方法,希望能帮助广大读者在实际工作中避免这个已知安全漏洞。


[- 7 -] 通俗易懂:一篇掌握即时通讯的消息传输安全原理

[链接] http://www.52im.net/thread-970-1-1.html

[摘要] 本文将通过通俗易懂的文字,引导你一步步理解为何一个即时通讯应用需要加密技术,以及需要何种方式的加密技术等,希望能为您的IM或消息推送服务的设计提供一些参考。


[- 8 -]  IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token

[链接] http://www.52im.net/thread-1525-1-1.html

[摘要] 本文讨论的使用Http短连接的话题可能并不适用于微信这样的IM,因为微信的短连接并非使用Http标准协议实现,而是基于自研的Mars网络层框架再造了一套短连接机制,从而更适用于IM这种场景(更低延迟、更省流量、更好的弱网适应算法等)


[- 9 -] 快速读懂量子通信、量子加密技术

[链接] http://www.52im.net/thread-1604-1-1.html

[摘要] 量子通信技术是个很高端的话题,对于搞IM、推送、网络通信的程序员来说,这到底是个什么鬼?所以我们一起来了解一下!


[- 10 -] 即时通讯安全篇(七):如果这样来理解HTTPS原理,一篇就够了

[链接] http://www.52im.net/thread-1890-1-1.html

[摘要] 本文将尝试用通俗易懂的语言,一步步还原HTTPS的设计过程,以便您能轻松理解为什么HTTPS最终会是这副模样。


[- 11 -] 一分钟理解 HTTPS 到底解决了什么问题

[链接] http://www.52im.net/thread-2027-1-1.html

[摘要] 本文只做简单的描述,力求简单明了的阐明主要内容,因为HTTPS 体系非常复杂,这么短的文字是无法做到很详细和精准的分析。想要详细了解HTTPS的方方面面,可以阅读此前即时通讯网整理的《即时通讯安全篇(七):如果这样来理解HTTPS,一篇就够了》一文。


[- 12 -] 一篇读懂HTTPS:加密原理、安全逻辑、数字证书等

[链接] http://www.52im.net/thread-2446-1-1.html

[摘要] HTTPS(全称:Hypertext Transfer Protocol Secure,超文本传输安全协议),是以安全为目标的HTTP通道,简单讲是HTTP的安全版。本文,就来深入介绍下其原理。


[- 13 -] 基于Netty的IM聊天加密技术学习:一文理清常见的加密概念、术语等

[链接] http://www.52im.net/thread-4104-1-1.html

[摘要] 本文正好借此机会,以Netty编写的IM聊天加密为例,为入门者理清什么是PKI体系、什么是SSL、什么是OpenSSL、以及各类证书和它们间的关系等,并在文末附上简短的Netty代码实示例,希望能助你通俗易懂地快速理解这些知识和概念!


[- 14 -] 手把手教你为基于Netty的IM生成自签名SSL/TLS证书

[链接] http://www.52im.net/thread-4142-1-1.html

[摘要] 本文要分享的是如何使用OpenSSL生成在基于Netty的IM中真正可用的SSL/TLS证书,内容包括:证书的创建、创建过程中的注意点,以及在Server端、Android端、iOS端、Java桌面端、H5端使用证书的代码范例。


[- 15 -] 微信技术分享:揭秘微信后台安全特征数据仓库的架构设计

[链接] http://www.52im.net/thread-4374-1-1.html

[摘要] 本文将介绍微信的安全数据特征仓库的背景起源、技术演进、当前的架构设计和实践,以及数据质量保证系统的实现。希望给中大型IM系统的安全数据特征仓库的设计带来启发。


👉52im社区本周新文:《微信团队分享:详解iOS版微信视频号直播中因帧率异常导致的功耗问题》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-11-15 10:51 Jack Jiang 阅读(49) | 评论 (0)编辑 收藏

本文由小红书基础架构存储组空洞和刘备分享,原题“小红书如何应对万亿级社交网络关系挑战?图存储系统 REDtao 来了!”,本文有修订和改动。

1、引言

小红书是一个社区属性为主的产品,它涵盖了各个领域的生活社区,并存储海量的社交网络关系。

为了解决社交场景下超大规模数据的更新与关联读取问题,并减少数据库压力和成本,我们自研了面向超大规模社交网络的图存储系统 REDtao,大大提高了系统稳定性。该系统借鉴了 Facebook 的图存储系统设计,将缓存和底层数据库封装起来,并对外提供统一的图查询 API,实现了访问收敛,同时在缓存中实现了高效的边聚合。

本文将为你分享小红书面向超大规模社交网络的图存储系统REDtao的架构设计与技术实践过程,希望能带给你启发。

 
 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4495-1-1.html

2、关于作者

空洞:小红书基础架构存储组,负责图存储系统 REDtao 和分布式缓存的研发。

刘备:小红书基础架构存储组负责人,负责REDkv / REDtao / REDtable / REDgraph 的整体架构和技术演进。

基础架构存储组是给小红书的业务部门提供稳定可靠的存储和数据库服务,满足业务对存储产品的功能、性能、成本和稳定性要求。目前负责自研分布式 KV、分布式缓存、图存储系统、图数据库和表格存储。

已上线的存储产品包括:

  • 1)REDkv : 分布式高性能 KV;
  • 2)REDtao :满足一跳查询的高性能图存储数据库;
  • 3) REDtable :提供 Schema 语义和二级索引的表格存储;
  • 4) REDgraph :提供两跳及以上的图语义查询数据库。

3、技术背景

小红书是以年轻人为主的生活记录、分享平台,用户可以通过短视频、图文等形式记录生活点滴,分享生活方式。

在小红书的社交领域里,我们有用户、笔记、商品等实体,这些实体之间有各种各样的关系。

例如:用户与笔记之间可能存在“拥有”(发布)、“点赞”、“收藏”等三种关系,同时还存在对应的反向关系“被点赞”,“被收藏”等。

小红书的社交图谱数据已经达到了万亿条边的规模,且增长速度非常快。当用户登陆小红书时,每个用户都会看到关注的好友、粉丝、点赞、收藏以及其他为其量身定做的内容。

这些信息高度个性化,需要实时从这些海量社交关系数据中读取用户相关信息。这是一个读为主的过程,读取压力非常大。

过去,我们将这些社交图谱数据都存储在运维成熟的 MySQL 数据库中。

然而,即使我们只有百万请求每秒的规模,MySQL 的 CPU 使用率仍然到达了 55% 。随着用户和 DAU 爆发式的增长,需要不断扩容 MySQL 数据库,这带来了巨大的成本和稳定性压力。

为了解决这些问题且考虑到没有合适的开源方案,2021 年初我们开启了从 0 到 1 自研 REDtao 的历程。

4、方案调研和API设计

4.1方案调研

我们充分调研了业内其他厂商的实现,发现有着强社交属性的公司基本上都有一个自研的图存储系统(如下图所示)。

比如:

  • 1)Facebook 实现了一个叫做 “TAO” 专门的分布式社交图谱数据库,并将其作为最核心的存储系统;
  • 2)Pinterest 和 Facebook 类似,也实现了类似的图存储系统;
  • 3)字节跳动自研了 ByteGraph 并将其用于存储核心的社交图谱数据;
  • 4)Linkedln 在 KV 之上构建了社交图谱服务。

考虑到当时我们的社交图谱数据已经存放在 MySQL 数据库上且规模巨大,而社交图谱数据服务是非常重要的服务,对稳定性的要求非常高。回溯 Facebook 当年遇到的问题和我们类似,数据存储在 Memcache 和 MySQL 中。因此,参考 Facebook 的 Tao 图存储系统更贴合我们的实际情况和已有的技术架构,风险更小。

4.2API设计

社交图谱的访问主要是边的关系查询。

我们的图模型将关系表示为一个 <key, value> 对,其中 key 是 ( FromId,  AssocType,  ToId ) 的三元组,value 是属性的  JSON 格式。

比如“用户 A ”关注“用户 B ”,映射到 REDtao 的数据存储结构为:

1<FromId:用户A的ID, AssocType:关注, ToId:用户B的ID>  ->  Value (属性的json字段)

我们对业务方的需求进行分析,封装了 25 个图语义的 API 给业务方使用,满足了其增删改查的需求,并收敛业务方的使用方式。

相比于 Facebook 的 Tao,我们还补充了社交图谱所需要的图语义,为反作弊场景提供了额外的过滤参数。

同时,在缓存层面,我们支持对不同的字段在缓存中配置局部二级索引。

下面给一些典型的使用场景。

1)场景一:获取关注了 A 的所有正常用户(并且剔除作弊用户):

1getAssocs(“被关注类型”, 用户A的ID, 分页偏移量, 最大返回值, 只返回正常用户,是否按照时间从新到旧)

2)场景二:获取 A 的粉丝个数(并且剔除作弊用户):

1getAssocCount(“被关注类型”, 用户A的ID, 只返回正常用户)

5、整体架构设计

REDtao 的架构设计考虑了下面这几个关键的要素:

整体架构分为三层:

  • 1)接入层;
  • 2)缓存层;
  • 3)持久层。

业务方通过 REDtao SDK 接入服务。

如下图:

在这个架构中:和 Facebook Tao 不一样的是,我们的缓存层是一个独立的分布式集群,和下面的持久层是解耦的。缓存层和下面的持久层可以独立的扩容缩容,缓存分片和 MySQL 分片不需要一一对应,这样带来了更好的灵活性,MySQL 集群也变成了一个可以插拔替换的持久存储。

1)读流程:客户端将读请求发送给 router,router 接收到 RPC 请求后,根据边类型选择对应的 REDtao 集群,根据三元组 ( FromId,  AssocType,  ToId ) 通过一致性 Hash 计算出分片所在的 Follower 节点,将请求转发到该节点上。Follower 节点接收到该请求,首先查询本地的图缓存,如果命中则直接返回结果。如果没有命中,则将请求转发给 Leader 节点。同样的,Leader 节点如果命中则返回,如果不命中则查询底层 MySQL 数据库。

2)写流程:客户端将写请求发送给 router,和读流程一样,会转发到对应的 Follower 节点上。Follower 节点会转发写请求给 Leader 节点,Leader 节点转发给 MySQL,当 MySQL 返回写入成功后,Leader 会清除本地图缓存对应的 Key,并同步给其他所有 Follower 清除掉该 Key,保证数据的最终一致性。

6、高可用设计

REDtao 分为独立的两层:缓存层和持久层。每一层都保证高可用性。

1)自研的分布式缓存:

我们自研了实现图语义的分布式 cache 集群,支持故障自动检测和恢复、水平扩缩容。

它是一个双层 cache,每个分片都有一个 Leader 和若干个 Follower。所有的请求都先发给外层的 Follower,再由 Follower 转发给 Leader。这样的好处是读压力大的时候只需要水平扩展 Follower,单点 Leader 写入的方式也降低了复杂度,更容易实现数据的一致性。

如果一个副本故障,系统会在秒级别内进行切换。当持久层发生故障时,分布式缓存层仍然可以对外提供读取服务。

2)高可用的MySQL集群:

MySQL 集群通过自研的中间件实现了分库分表方案,并支持 MySQL 的水平扩容。每个 MySQL 数据库有若干从库,并且与公司内部其他的 MySQL 运维方案一致,保证高可用性。

3)限流保护功能:

为防止缓存击穿导致 MySQL 突发大量请求,从而导致 MySQL 宕机,我们通过限制每个主节点最大 MySQL 并发请求数来实现限流保护 MySQL。达到最大并发请求限制之后的请求会被挂起等待,直到已有请求被处理返回,或者达到等待超时请求被拒绝不会被继续请求到 MySQL 。限流阈值在线可调,根据 MySQL 集群规模调整对应限制。

为防止爬虫或者作弊用户频繁刷同一条数据,我们利用 REDtaoQueue 顺序执行对写入或者点查同一条边的请求,队列长度会被限制,控制同一时间大量相同的请求执行。相比于单个全局的队列控制所有请求的方式,基于每个请求的队列可以很好地限制单个同一请求,而不影响其他正常请求。

7、高性能设计

数据结构的设计是 REDtao 高性能的重要保证。

我们采用了三层嵌套 HashTable 的设计, 通过根据某个起点 from_id 从第一级 HashTable 中查找到 REDtaoGraph,记录了所有 type 下对应的所有的出边信息。

接着,在第二级 HashTable 中,根据某个 type_id 查找到 AssocType 对应某个 type 下边所有出边的计数、索引以及其他元数据。

最终在最后一级 HashTable ,通过 AssocType 的某个 to_id 查找到最终边信息。

我们记录了创建时间、更新时间、版本、数据以及 REDtaoQueue,time_index 则对应根据创建时间排序列表。

最后一级 HashTable 以及索引限制存储最新的 1000 个边信息,以限制超级点占据过多内存,同时集中提高最新热数据的查询命中率以及效率。REDtaoQueue 用于排队当前某个关系的读写,只记录了当前最后一个请求的元数据。

每次查询或写入时,首先查询 REDtaoAssoc:

  • 1)若缓存不存在,则会首先创建只包含 REDtaoQueue 的对象;
  • 2)若缓存已存在,则会更新队列元数据,将自己设置为队列的最后一个请求,并挂起等待被执行。

通过这种多层 hash+ 跳表的设计,我们能高效地组织点、边、索引、时间序链表之间的关系。内存的申请、释放在同一个线程上完成。

在线上环境中,我们的系统可以在一台 16 核的云厂商虚拟机上跑到 150w 查询请求/s,同时 CPU 利用率仅有 22.5% 。下方是线上集群的一个监控图,单机的 QPS 到达 3w ,每个 RPC 请求聚合了 50 个查询。

 

8、易用性设计

1)丰富的图语义 API :

我们在 REDtao 中封装了 25 个图语义的 API 给业务方使用,满足了业务方的增删改查的需求。业务方无需自行编写 SQL 语句即可实现相应操作,使用方式更加简单和收敛。

2)统一的访问 URL :

由于社区后端数据太大,我们按照不同的服务和优先级拆分成了几个 REDtao 集群。

为了让业务方不感知后端的集群拆分逻辑,我们实现了统一的接入层。

不同的业务方只需使用同一个服务 URL ,通过 SDK 将请求发送到接入层。接入层会接收到不同业务方的图语义的请求,并根据边的类型路由到不同的 REDtao 集群。它通过订阅配置中心,能够实时感知到边的路由关系,从而实现统一的访问 URL,方便业务方使用。

9、数据一致性设计

作为社交图谱数据,数据的一致性至关重要。我们需要严格保证数据的最终一致性以及一定场景下的强一致性。为此,我们采取了以下措施:

1)缓存更新冲突的解决:

REDtao 为每个写入请求生成一个全局递增的唯一版本号。在使用 MySQL 数据更新本地缓存时,需要比较版本号,如果版本号比缓存的数据版本低,则会拒绝此更新请求,以避免冲突。

2)写后读的一致性:

Proxy 会将同一个 fromId 的点或边请求路由到同一个读 cache 节点上,以保证读取数据一致性。

3)主节点异常场景:

Leader 节点收到更新请求后,会将更新请求变为 invalidate cache 请求异步的发送给其他 follower,以保证 follower 上的数据最终一致。在异常情况下,如果 Leader 发送的队列已满导致 invalidate cache 请求丢失,那么会将其他的 follower cache 全部清除掉。

如果 Leader 故障,新选举的 Leader 也会通知其他 follower 将 cache 清除。

此外,Leader 会对访问 MySQL 的请求进行限流,从而保证即使个别分片的cache被清除掉也不会将 MySQL 打崩。

4)少量强一致的请求:

由于 MySQL 的从库也提供读服务,对于少量要求强一致的读请求,客户端可以将请求染上特殊标志,REDtao 会透传该标志,数据库 Proxy 层会根据该标志将读请求转发到 MySQL 主库上,从而保证数据的强一致。

10、 跨云多活设计

跨云多活是公司的重要战略,也是 REDtao 支持的一个重要特性。

REDtao 的跨云多活架构整体如下:

这里不同于 Facebook Tao 的跨云多活实现,Facebook Tao 的跨云多活实现如下图所示。

Facebook 的方案依赖于底层的 MySQL 的主从复制都通过 DTS Replication 来做。而 MySQL 原生的主从复制是自身功能,DTS 服务并不包含 MySQL 的主从复制。该方案需要对 MySQL 和 DTS 做一定的改造。前面说到,我们的缓存和持久层是解藕的,在架构上不一样。

因此,REDtao 的跨云多活架构是我们结合自身场景下的设计,它在不改动现有 MySQL 功能的前提下实现了跨云多活功能。

1)持久层我们通过 MySQL 原生的主从 binlog 同步将数据复制到其他云的从库上。其他云上的写请求和少量要求强一致读将被转发到主库上。正常的读请求将读取本区的 MySQL 数据库,满足读请求对时延的要求。

2)缓存层的数据一致性是通过 MySQL DTS 订阅服务实现的,将 binlog 转换为 invalidate cache 请求,以清理掉本区 REDtao cache 层的 stale 数据。由于读请求会随机读取本区的任何一个 MySQL 数据库,因此 DTS 订阅使用了一个延迟订阅的功能,保证从 binlog 同步最慢的节点中读取日志,避免 DTS 的 invalidate cache 请求和本区 read cache miss 的请求发生冲突从而导致数据不一致。

11、云原生实现

REDtao 的云原生特性重点体现在弹性伸缩、支持多 AZ 和 Region 数据分布、产品可以实现在不同的云厂商间迁移等几个方面。REDtao 在设计之初就考虑到支持弹性扩缩容、故障自动检测及恢复。

随着 Kubernetes 云原生技术越来越成熟,我们也在思考如何利用 k8s 的能力将部署和虚拟机解绑,进一步云原生化,方便在不同的云厂商之间部署和迁移。

REDtao 实现了一个运行在 Kubernetes 集群上的 Operator,以实现更快的部署、扩容和坏机替换。

为了让 k8s 能感知集群分片的分配并且控制同一分片下的 Pods 调度在不同宿主机上,集群分组分片分配由 k8s Operator 渲染并控制创建 DuplicateSet (小红书自研 k8s 资源对象)。

REDtao 则会创建主从并根据 Operator 渲染出来的分片信息创建集群,单个 Pod 故障重启会重新加入集群,无需重新创建整个集群。集群升级时,Operator 通过感知主从分配控制先从后主的顺序,按照分片分配的顺序滚动升级以减少升级期间线上影响。

12、老服务的平滑升级实践

但凡变革,皆属不易。实现全新的 REDtao 只是完成了相对容易的那部分工作。

小红书的社交图谱数据服务已经在 MySQL 上运行多年,有很多不同的业务跑在上面,任何小的问题都会影响到小红书的在线用户。因此,如何保证不停服的情况下让现有业务无感知地迁移到 REDtao 上成为一个非常大的挑战。

我们的迁移工作关键有两点:

1)将老的大 MySQL 集群按优先级拆分成了四个 REDtao 集群。这样,我们可以先将优先级最低的服务迁移到一个 REDtao 集群,充分灰度后再迁移高优先级的集群;

2)专门开发了一个 Tao Proxy SDK,支持对原来的 MySQL 集群和 REDtao 集群进行双写双读,数据校验比对。

迁移时:我们首先将低优先级的数据从 MySQL 通过 DTS 服务迁移到了一个 REDtao 集群,并升级好业务方的 SDK 。DTS 服务一直对增量数据进行同步。业务方 SDK 会订阅配置中心的配置变更,我们修改配置让 Tao Proxy SDK 同时读写 MySQL 集群和 REDtao 集群,并关闭 DTS 服务。此时会使用 MySQL 集群的结果返回给用户。

在停止 DTS 服务时:有可能会有新的 MySQL 数据通过 DTS 同步过来,造成了 REDtao 集群新写的数据被同步过来的老数据覆盖。因此,在关闭 DTS 服务后,我们会通过工具读取开双写之后到关闭 DTS 服务这个时间段的 binlog 对数据进行校验和修复。

修复完成之后:Tao Proxy SDK 的双读会展示两边不一致的数据量,并过滤掉因为双写时延不一致导致数据不一致的请求。灰度一段时间后观察到 diff 的数目基本为 0,将 Tao Proxy SDK 的配置改为只读写新的 REDtao 集群。

最终:我们在 22 年初完成小红书所有核心社交图谱万亿边级别数据的迁移和正确性校验,并做到了整个迁移服务无感知,迁移过程没有发生一起故障。

13、新图存储系统带来的结果和收益

我们的社交图谱数据访问中,90% 以上的请求都是读请求,并且社交图谱的数据有非常强的时间局部性(即最近更新的数据最容易被访问)。REDtao 上线后,获得 90% 以上的 cache 命中率, 对MySQL 的 QPS 降低了 70%+ ,大大降低了 MySQL 的 CPU 使用率。在缩容 MySQL 的副本数目后,整体成本降低了21.3%。‍

业务的访问方式都全部收敛到 REDtao 提供的 API 接口上,在迁移过程中,我们还治理了一些老的不合理访问 MySQL 数据库的方式,以及自定义某些字段赋予特殊含义的不合理做法,通过 REDtao 规范了数据访问。

对比 2022 年初和 2023 年初,随着 DAU 的增长,社交图谱的请求增长了 250% 以上,如果是之前 MySQL 的老架构,扩容资源基本上和请求增长速度成正比,至少需要扩容 1 倍的资源成本(数万核)。

而得益于 REDtao 系统的存在,因其 90% 的缓存命中率,实际上整体成本只增加了 14.7%(数千核)就能扛下 2.5 倍的请求增长。在成本和稳定性上有了较大的提升。

14、未来展望

在较短的时间,我们自研了图存储系统 REDtao ,解决了社交图谱关系数据快速增长的问题。

REDtao 借鉴了 FaceBook Tao 的论文,并对整体架构、跨云多活做了较多的改进,全新实现了一个高性能的分布式图缓存,更加贴合我们自身的业务特点和提供了更好的弹性。同时,利用 k8s 能力进一步实现了云原生化。

随着 DAU 的持续增长,万亿的数据规模也在继续增长,我们也面临着更多的技术挑战。

目前公司内部的 OLTP 图场景主要分为三块:

1)社交图谱数据服务:通过自研图存储系统 REDtao 满足了社交场景超大规模数据的更新与关联读取问题。目前已经存储了万亿规模的关系;

2)风控场景:通过自研图数据库 REDgraph,满足多跳的实时在线查询。目前存储了千亿点和边的关系,满足 2 跳以及 2 跳以上的查询;

3)社交推荐:这块主要是两跳的查询。每天通过 Hive 批量地导入全量的数据,通过 DTS 服务近实时的写入更新数据。因为是在线场景,对时延的要求非常高,当前的 REDgraph 还无法满足这么高的要求,因此业务方主要是用 REDkv 来存储。

针对以上场景:为了快速满足业务需求,我们使用了三套不同的自研存储系统:REDtao 、REDgraph 和 REDkv 。

显然相对于 3 套存储系统,用一个统一的架构和系统去解决这几个图相关的场景是更加合适的。

未来:我们会将 REDgraph 和 REDtao 融合成一个统一的数据库产品,打造业内顶尖的图技术,对公司内部更多的场景进行赋能。

15、相关资料

[1] 以微博类应用场景为例,总结海量社交系统的架构设计步骤

[2] 腾讯技术分享:社交网络图片的带宽压缩技术演进之路

[3] 基于社交网络的Yelp是如何实现海量用户图片的无损压缩的?

[4] 社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等

[5] 社交软件红包技术解密(六):微信红包系统的存储层架构演进实践

[6] 社交软件红包技术解密(九):谈谈手Q红包的功能逻辑、容灾、运维、架构等

[7] 渐行渐远的人人网:十年亲历者的互联网社交产品复盘和反思

[8] 中国互联网社交二十年:全民见证的互联网创业演义

[9] 盘点移动互联网时代的社交产品进化史(上篇):谁主沉浮

[10] 盘点移动互联网时代的社交产品进化史(下篇):大浪淘沙


(本文已同步发布于:http://www.52im.net/thread-4495-1-1.html

posted @ 2023-11-09 11:21 Jack Jiang 阅读(77) | 评论 (0)编辑 收藏

​为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第22 期。

[- 1 -] 即时通讯安全篇(一):正确地理解和使用Android端加密算法

[链接] http://www.52im.net/thread-216-1-1.html

[摘要] 本文主要讨论针对Android这样的移动端应用开发时,如何正确的理解目前常用的加密算法,为诸如即时通讯应用的实战开发,如何在合适的场景下选择适合的算法,提供一些参考。


[- 2 -] 即时通讯安全篇(二):探讨组合加密算法在IM中的应用

[链接] http://www.52im.net/thread-217-1-1.html

[摘要] 本文深入分析了即时通信(IM)系统中所面临的各种安全问题,综合利用对称加密算法(DES算法)、公开密钥算法(RSA算法)和Hash算法(MD5)的优点,探讨组合加密算法在即时通信中的应用。


[- 3 -] 即时通讯安全篇(三):常用加解密算法与通讯安全讲解

[链接] http://www.52im.net/thread-219-1-1.html

[摘要] 本次着重整理了常见的通讯安全问题和加解密算法知识与即时通讯(IM)开发同行们一起分享和学习。


[- 4 -] 即时通讯安全篇(四):实例分析Android中密钥硬编码的风险

[链接] http://www.52im.net/thread-312-1-1.html

[摘要] 本文主要借用乌云上已公布的几个APP漏洞来讲讲这其中的潜在风险和危害。


[- 5 -] 即时通讯安全篇(五):对称加密技术在Android平台上的应用实践

[链接] http://www.52im.net/thread-642-1-1.html

[摘要] 本文将重点分享对称加解密技术在Android平台上的实践应用。对于即时通讯社区里的IM、推送技术的开发者同行而言,是不可多得的第一手实践资料,希望对你有用。


[- 6 -] 即时通讯安全篇(六):非对称加密技术的原理与应用实践

[链接] http://www.52im.net/thread-653-1-1.html

[摘要] 本文将要分享的是非对称加密技术在当前互联网场景下的应用情况。


[- 7 -] 即时通讯安全篇(七):用JWT技术解决IM系统Socket长连接的身份认证痛点

[链接] http://www.52im.net/thread-2106-1-1.html

[摘要] 本次分享正是基于此次解决Socket长连接身份安全认证的实践总结而来,方案可能并不完美,但愿能起到抛砖引玉的作用,希望能给您的IM系统开发带来启发。


[- 8 -]  即时通讯安全篇(八):你知道,HTTPS用的是对称加密还是非对称加密?

[链接] http://www.52im.net/thread-2866-1-1.html

[摘要] 本文将带你了解HTTPS到底用的是对称加密还是非对称加密,以及具体又是怎么使用的。


[- 9 -] 即时通讯安全篇(九):为什么要用HTTPS?深入浅出,探密短连接的安全性

[链接] http://www.52im.net/thread-3897-1-1.html

[摘要] 今天就借此机会,跟大家一起深入学习一下HTTPS的相关知识,包括HTTP的发展历程、HTTP遇到的问题、对称与非对称加密算法、数字签名、第三方证书颁发机构等概念。


[- 10 -] 即时通讯安全篇(十):IM聊天系统安全手段之通信连接层加密技术

[链接] http://www.52im.net/thread-4015-1-1.html

[摘要] 本篇文章将围绕IM通信连接层的安全问题及实现方案,聚焦IM网络“链路安全”,希望能带给你启发 。


[- 11 -] 即时通讯安全篇(十一):IM聊天系统安全手段之传输内容端到端加密技术

[链接] http://www.52im.net/thread-4026-1-1.html

[摘要] 本篇将围绕IM传输内容的安全问题,以实践为基础,为你分享即时通讯应用中的“端到端”加密技术。


[- 12 -] 传输层安全协议SSL/TLS的Java平台实现简介和Demo演示

[链接] http://www.52im.net/thread-327-1-1.html

[摘要] 本文将简要介绍Java平台的SSL/TLS实现并以Demo示例的方式予以讲解。


[- 13 -] 理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)

[链接] http://www.52im.net/thread-283-1-1.html

[摘要] 本文将以理论联系实际的方式,详细讲解一套典型IM的通信协议设计的方方面面。


👉52im社区本周新文:《小红书万亿级社交网络关系下的图存储系统的架构设计与实践http://www.52im.net/thread-4495-1-1.html》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-11-06 13:45 Jack Jiang 阅读(40) | 评论 (0)编辑 收藏

     摘要: 本文由得物技术WWQ分享,原题“客服发送一条消息背后的技术和思”,本文有修订和改动。1、引言在企业IM客服场景中,客服发送一条消息的背后,需要考虑网络通信、前端展示、后端存储以及安全性等多个方面的技术支持。单从前端层面来说,就需要考虑到消息的显示、状态更新、稳定传输以及极限操作消息不卡顿等场景。随着IM系统的不断更新迭代,已经实现了从外采到自研再到一站式全场景工作台的搭建,...  阅读全文

posted @ 2023-11-02 11:02 Jack Jiang 阅读(77) | 评论 (0)编辑 收藏

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅支持 UDP 、TCP 、WebSocket 三种协议,支持 iOS、Android、H5、标准Java、小程序、Uniapp,服务端基于Netty编写。

工程开源地址是:


关于RainbowChat

► 详细产品介绍:http://www.52im.net/thread-19-1-1.html
► iOS端更新记录:http://www.52im.net/thread-2735-1-1.html
► 全部运行截图:iOS端全部运行截图 (另:Android端运行截图 点此查看
► 在线体验下载:App Store安装地址 (另:Android端下载体验 点此查看

 

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题(可自行下载体验:专业版下载安装)。

RainbowChat可能是市面上提供im即时通讯聊天源码的,唯一一款同时支持TCP、UDP两种通信协议的IM产品(通信层基于开源IM聊天框架 MobileIMSDK 实现)。


v8.0 版更新内容

此版更新内容更多历史更新日志):

  • 1)[新增] 新增了“群名片”功能;
  • 2)[新增] 新增了消息转发功能;
  • 3)[新增] 安全提升,启用了AppKey校验机制;
  • 4)[优化] 安全提升,优化了http接口、文件上传接口、socket长连接的token校验逻辑;
  • 5)[优化] 更换了新的高德地图websevice key;
  • 6)[优化] 其它ui细节和bug优化等。

此版新增功能运行截图(更多截图点此查看):

posted @ 2023-11-01 11:46 Jack Jiang 阅读(43) | 评论 (0)编辑 收藏

     摘要: 本文由序员先生分享,原题“技术解读企业微信之四维关系链”,本文有修订和改动。1、引言3年疫情后的中国社会,最大的永久性变化之一,就是大多数的企业、教育机构或者政务机构,都用上了综合性的SaaS在线办公系统。而这其中,企业微信的覆盖率非常高,而且其占比还在不断增长。越来越多的人因此好奇,开始想要更深度的了解企业微信,自然也就有越来越多的人开始解读企业微信。而解读的角度,五花八...  阅读全文

posted @ 2023-10-26 10:36 Jack Jiang 阅读(67) | 评论 (0)编辑 收藏

     摘要: 本文由大淘宝终端平台技术团队沈良炜(沛轩)分享,本文有修订和改动。1、引言自 2013 年 ALLIN 无线到今天,已经走过 10 个年头,淘宝终端统一网络库 AWCN (Ali Wireless Connection Network) 从淘内孵化,一路过来伴随着淘宝业务的发展,经历集团 IPv6 战役、协议升级演进等,逐步沉淀为阿里集团终端网络通用解决方案,是兼具高性能、多协议、可容灾、可观测的...  阅读全文

posted @ 2023-10-19 14:10 Jack Jiang 阅读(91) | 评论 (0)编辑 收藏

本文由百度技术王伟分享,原题“视频中为什么需要这么多的颜色空间?”,本文收录时有修订和改动。

1、引言

在视频处理中,我们经常会用到不同的色彩空间:非线性RGB,线性 RGB,YUV,XYZ……为什么需要这么多的色彩空间呢?为什么在 FFMpeg 中会有 color_space,color_transfer,color_primaries 等一系列的颜色属性呢?这些术语之间究竟隐藏着什么秘密?

本文将以通俗易懂的文字,引导你理解视频是如何从采集开始,历经各种步骤,最终通过颜色模型转换和不同的色域转换,让你看到赏心悦目的视频结果的。

 
 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4467-1-1.html

2、系列文章

本文是系列文章中的第20篇,本系列文章的大纲如下:

即时通讯音视频开发(一):视频编解码之理论概述

即时通讯音视频开发(二):视频编解码之数字视频介绍

即时通讯音视频开发(三):视频编解码之编码基础

即时通讯音视频开发(四):视频编解码之预测技术介绍

即时通讯音视频开发(五):认识主流视频编码技术H.264

即时通讯音视频开发(六):如何开始音频编解码技术的学习

即时通讯音视频开发(七):音频基础及编码原理入门

即时通讯音视频开发(八):常见的实时语音通讯编码标准

即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述

即时通讯音视频开发(十):实时语音通讯的回音消除技术详解

即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解

即时通讯音视频开发(十二):多人实时音视频聊天架构探讨

即时通讯音视频开发(十三):实时视频编码H.264的特点与优势

即时通讯音视频开发(十四):实时音视频数据传输协议介绍

即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况

即时通讯音视频开发(十六):移动端实时音视频开发的几个建议

即时通讯音视频开发(十七):视频编码H.264、V8的前世今生

即时通讯音视频开发(十八):详解音频编解码的原理、演进和应用选型

即时通讯音视频开发(十九):零基础,史上最通俗视频编码技术入门

即时通讯音视频开发(二十):一文读懂视频的颜色模型转换和色域转换》(* 本文

3、视频采集

如上图所示,在相机系统中,外部世界的光信息(光子,photons)通过透镜或其他光学器件聚焦之后达到相机的图像传感器(CCD 或者 CMOS)。

过程是这样的:

  • 1)图像传感器可以将一个入射光子(photon)转换为对应的一个电子(electron);
  • 2)在曝光时间内,图像传感器对转换的电子进行电荷积累;
  • 3)然后,图像传感器会将积累的电荷信号转换成对应的电压信号;
  • 4)最后,利用 ADC 把电信号转换成数字信号,而转换后的数字信号则为某个范围内的整数值。

ADC 数字信号的取值范围 :

[pquote]ADC 转换之后的数字信号的取值范围受限于 ADC 设备。对于 8-bits 的 ADC 而言,数字信号的取值范围为 [0, 2^8-1],因此,对于每一个像素而言,会用 [0, 255] 之间的整数来进行编码。[/pquote]

ADC 转换的数字信号的数值是一个线性编码的过程,这意味着如果将图像传感器上的光量增加 1 倍,则 ADC 转换之后对应的数值也会增加 1 倍。

这是一个非常有用的特性:无论是增加物理世界的光量,还是增加 ADC 转换之后的数值,对图片而言,都会带来相同的效果。线性编码意味着我们所处理的数据和光发射的强度成正比关系。

由数码相机中的 CMOS 传感器产生并写入原始文件(Raw File)的数据是线性的。与普通照片相比,线性数据通常看起来非常暗且对比度较低。

在 iPhone 手机中,可以通过设置相机来拍摄 Apple ProRAW 格式的照片。

4、探索视频伽马校正

研究表明:人类视觉系统是以对数函数的方式来感知光亮度。这意味着:人眼会提高暗部的敏感度,降低高光部分的敏感度。

从数学角度看,感知光强度和测量光强度之间存在一个*似的*方关系,具体如下式所示。

由于人类视觉感知系统不是以线性方式工作的,因此必须使用非线性曲线来对 ADC 生成的的线性数据进行变换,从而使得拍摄的图像色调与我们的视觉系统的工作方式相匹配。这个过程也就是我们所说的 伽马校正。

因此:在从线性 RGB 空间转换到非线性 RGB 空间时,需要 γ 作为转换参数。相机中的 ISP 模块负责对图像传感器的线性 RGB 进行伽马校正进而产生对应的符合人眼感知的非线性 RGB 数据。

RGB 的设备依赖性 :

不同显示设备支持的色域空间不同,因此对于不同的显示设备而言,伽马校正之后的 RGB 数值也不同。从这个角度讲,RGB 是设备依赖型的色彩空间。

5、视频压缩

根据如上的信息,我们知道:相机系统经过 ISP 处理之后,最终会得到非线性的 RGB 信息。对于视频而言,如果以 RGB 存储每帧的信息,则需要消耗大量的存储空间。

人类视觉系统对颜色信息的敏感度要弱于亮度信息。利用这一特点,通常相机会将捕获的 RGB 信息转换为 YUV 格式,然后对 YUV 格式进行色度信息采样(例如,YUV420)以便压缩图像空间。

RGB->YUV,不同标准有不同要求,一般常用的标准有:

  • 1)BT. 601(SD: Standard-Definition);
  • 2)BT. 709(HD: High-Definition);
  • 3)BT. 2020(UHD: Ultra-High-Definition)。

注意 :

标准中,不但会规定 RGB->YUV 的转换系数,同时还会规定从线性 RGB 到非线性 RGB 转换的 gamma 系数。

将 RGB颜色模型,转换成 YUV 模型后,接下来会采用某种视频编解码算法(例如,H265, VP9)对获取的数据进行视频编码,最终得到视频文件(此处忽略了音频的采集编码以及合流的操作)。

6、视频转码

出于各种原因,例如:

  • 1)终端用户的带宽受限;
  • 2)终端用户支持的视频编解码算法和相机压缩视频的编解码算法不一致;
  • 3)……

一般不会直接把相机产出的视频文件分发给用户去消费。媒体服务商会对相机生成的视频文件进行转码,然后选择合适的转码后的视频分发给终端消费用户。

在视频转码阶段,如果我们希望对原视频进行色域的变换,例如从 BT. 601 转码为 BT. 709,则需要在不同色域的 RGB 数值之间进行转换。

在不同的色域空间进行 RGB 数据的转换,这也就是我们所说的 色彩管理。色彩管理会对图像进行色彩管理以适配当前环境下的颜色效果,从而保证同一张图片在不同输入、输出上都呈现出最好的颜色。

色彩转换需要在某个线性空间下进行操作,并且操作过程需要保持设备的独立性。因此,不同的 RGB 色域空间是不能直接进行转换的,需要一个设备无关、线性的颜色模型作为中转才能实现其转换。

而 XYZ(CIE 1931 XYZ color space)具备设备无关、线性操作的特性。

在 FFMpeg 中,主要使用 colorspace 滤镜 来完成不同色域空间的转换。

根据 colorspace 的实现可知,在 FFMpeg 中,BT. 601->BT. 709 的转换过程如下所示:

在如上的变换中,涉及到 3 个颜色空间的转换,分别是:

  • 1)YUV 和 RGB 之间的转换;
  • 2)线性 RGB 和非线性 RGB 之间的转换;
  • 3)线性 RGB 和 XYZ 之间的转换。

在 FFMpeg 中,所有的这些转换参数都保存在 AVFrame 结构中:

  • 1)AVFrame->colorspace 中保存了 YUV/RGB 的转换矩阵;
  • 2)AVFrame->color_trc 中保存了线性 RGB 和非线性 RGB 之间的转换函数(transformation characteristics);
  • 3)AVFrame->color_primaries 中保存了 RGB/XYZ 的转换矩阵;

如果用 ffprobe 命令解析视频文件,则:

  • 1)color_space 字段对应 YUV/RGB 的转换矩阵;
  • 2)color_transfer 字段对应线性 RGB 和非线性 RGB 之间的转换函数;
  • 3)color_primaries 字段对应 RGB/XYZ 的转换矩阵。

$ ffprobe -select_streams v:0 -show_entries stream=color_space,color_transfer,color_primaries test.mp4

 

[STREAM]

color_space=bt2020nc

color_transfer=arib-std-b67

color_primaries=bt2020

[/STREAM]

在如上的例子中,arib-std-b67 也就是我们所熟悉的 HLG。

在 MediaInfo 中:

  • 1)Matrix coefficients 字段对应 YUV/RGB 的转换矩阵;
  • 2)Transfer characteristic 字段对应线性 RGB 和非线性 RGB 之间的转换函数;
  • 3)Color primaries 字段对应 RGB/XYZ 的转换矩阵。

除了如上的参数外,AVFrame->range 还用来存储视频中对应像素的每个分量的取值范围。

在 vf_setparams.c 中也作了相关的定义说明:

{"limited", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},  0, 0, FLAGS, "range"},

{"tv",      NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},  0, 0, FLAGS, "range"},

{"mpeg",    NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_MPEG},  0, 0, FLAGS, "range"},

{"full",    NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},  0, 0, FLAGS, "range"},

{"pc",      NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},  0, 0, FLAGS, "range"},

{"jpeg",    NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_RANGE_JPEG},  0, 0, FLAGS, "range"},

7、视频解码&播放

7.1基本

转码之后的视频,可以通过各种渠道分发到终端用户进行消费。

对于大部分显示设备,例如CRT显示器、LCD、OLED,屏幕上的每个像素都是通过驱动三个非常靠*但仍然分开的小型 RGB 光源而构建的。

因此:显示屏(监视器、电视机、屏幕等等)仅使用 RGB 模型,并以不同的方式来组织,并显示最终的图像。

如前所述:不同的显示设备采用的 RGB 的色域并不一定相同,因此,RGB 是一种设备依赖型的颜色模型。在 Mac 电脑上,可以通过显示器配置来选择显示器支持不同的 RGB 色域。

7.2显示设备和相机的色域一致

如果编码视频和播放视频的显示器采用的 RGB 色域是一致的,比如都是 sRGB,此时的播放过程相对比较简单。

视频解码之后:得到 YUV 数据,然后根据标准将 YUV 数据转换成非线性的 sRGB 数据,然后显示器根据 sRGB 数据显示图像即可。

7.3显示设备和相机的色域不一致

当显示设备支持的色域从 sRGB 变为 Rec. 2020 时,如果直接显示 sRGB 色域下的数据,则会导致比较严重的颜色失真。

和转码阶段的色域转换类似,此时,也需要在不同的色域空间进行 RGB 数据的转换(色彩管理)以保证相同的视频在不同输入、输出、显示设备上都呈现出最好的颜色。

对于显示设备而言,sRGB->RGB(Rec. 2020)的转换过程如下所示:

因此:对于拍摄设备和显示设备的色域不同时,视频的播放增加了颜色管理的过程。

8、视频观看

虽然视频信息的采集和最终终端播放采用的都是 RGB 的颜色模型,但是对人眼而言,RGB 其实并不直观,比如我们很难马上反应出天青色的 RGB 色值?

为了能够更直观的表示颜色,又引入了 HSL 色彩模型。

HSL 比 RGB 更加直观,比如:想从黄色过度到红色,只需要调整色相即可,饱和度和亮度保持不变。因此,HSL 一般更适合人的色彩感知,而 RGB 更适合显示领域。

为了让作品可以呈现出期望的效果,提升用户的视觉体验,在摄影后期,使用 HSL 对作品进行调整是最方便的一种方式。利用 HSL 对作品进行调整,简单几步就可以让灰暗的「马路随拍」秒变「街头大片」。

FFMpeg 的 signalstats 滤镜可以分析获取视频的色调、饱和度、亮度信息。但是该滤镜获取的色调、饱和度和 HSL 中的计算 是不一致的。

signalstats 计算色调、饱和度的算法如下所示:

如果需要得到视频的标准 HSL 信息,可以使用作者开发的 vf_hsl 滤镜。

9、本文小结

虽然颜色还是那个颜色,但是不同的颜色空间的适用范围并不相同。

具体是:

  • 1)RGB:面向采集和显示设备;
  • 2)YUV:面向存储;
  • 3)HSL:面向人类视觉感知;
  • 4)XYZ:RGB之间的转换桥梁。

从视频采集到视频消费的整个过程,涉及到不同的设备和标准,而不同的设备和标准所支持的色域空间又不相同。

正是通过不同的颜色模型转换和不同的色域转换,才得以让我们实现:在不同输入、输出、显示设备上都呈现出最好的颜色,并以*似相同的观看体验来消费视频。

10、参考文献

[1] CMOS Image Sensor原理简述

[2] 数字视频导论

[3] 用HSL调色=简单、快速、超出片

[4] 零基础入门:实时音视频技术基础知识全面盘点

[5] 实时音视频面视必备:快速掌握11个视频技术相关的基础概念

[6] 轻松诙谐,讲解视频编解码技术的过去、现在和将来

[7] 写给小白的实时音视频技术入门提纲

[8] 福利贴:最全实时音视频开发要用到的开源工程汇总

[9] 详解音频编解码的原理、演进和应用选型

[10] 零基础,史上最通俗视频编码技术入门


(本文已同步发布于:http://www.52im.net/thread-4467-1-1.html

posted @ 2023-10-12 11:20 Jack Jiang 阅读(52) | 评论 (0)编辑 收藏

一、更新内容简介

本次更新为次要版本更新,进行了若干优化(更新历史详见:码云 Release NotesGithub Release Notes)。MobileIMSDK 可能是市面上唯一同时支持 UDP+TCP+WebSocket 三种协议的同类开源IM框架。

二、MobileIMSDK简介

MobileIMSDK 是一套专为移动端开发的原创IM通信层框架:

  • 历经10年、久经考验;
  • 超轻量级、高度提炼,lib包50KB以内;
  • 精心封装,一套API同时支持UDP、TCP、WebSocket三种协议(可能是全网唯一开源的);
  • 客户端支持 iOSAndroid标准JavaH5小程序Uniapp
  • 服务端基于Netty,性能卓越、易于扩展;👈
  • 可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等;👈
  • 可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。

MobileIMSDK工程始于2013年10月,历经10年,起初用作某产品的即时通讯底层实现,完全从零开发,技术自主可控!

您可能需要:查看关于MobileIMSDK的详细介绍

三、源码托管同步更新

OsChina.net

GitHub.com

四、MobileIMSDK设计目标

让开发者专注于应用逻辑的开发,底层复杂的即时通讯算法交由SDK开发人员,从而解偶即时通讯应用开发的复杂性。

五、MobileIMSDK框架组成

整套MobileIMSDK框架由以下7部分组成:

  1. Android客户端SDK:用于Android版即时通讯客户端,支持Android 2.3及以上,查看API文档
  2. iOS客户端SDK:用于开发iOS版即时通讯客户端,支持iOS 9.0及以上,查看API文档
  3. Java客户端SDK:用于开发跨平台的PC端即时通讯客户端,支持Java 1.6及以上,查看API文档
  4. H5客户端SDK查看精编注释版
  5. 微信小程序端SDK查看精编注释版
  6. Uniapp端SDK查看精编注释版
  7. 服务端SDK:用于开发即时通讯服务端,支持Java 1.7及以上版本,查看API文档

整套MobileIMSDK框架的架构组成:

 另外:MobileIMSDK可与姊妹工程 MobileIMSDK-Web 无缝互通,从而实现Web网页端聊天或推送等。

六、MobileIMSDK v6.4更新内容 

【重要说明】:

MobileIMSDK v6.4 为次要版本,进行了若干优化! 查看详情 (github

【新增重要特性】:

【解决的Bug】:

  • 1. [Uniapp端] 解决了Demo界面右上角的连接状态title无法更新的问题;
  • 2. [服务端] 解决桥接模式下与最新rabbitmq库不兼容从而断线重连不成功,导致MQ中消息堆积的问题。

【其它优化和提升】:

  • 1. [服务端] 解决登陆连接指令中的一处潜在空指针风险;
  • 2. [微信小程序端] 优化自带Demo中聊天主界面flex布局下的中部聊天列表高度自适应能力;
  • 3. [微信小程序端/H5端] 优化了Demo中的CSS代码;
  • 4. [微信小程序端/H5端] 优化了WebSocket的关闭逻辑,确保标准API中的close方法因异步调用带来socket实例被错误重置的问题;
  • 5. [H5端] 为Demo增加了消息送达状态图标的显示(包括发送中、发送成功、发送失败3种状态);
  • 6. [H5端] 重新设计了Demo的登录界面;
  • 7. [服务端] 升级amqp-client库至5.x版;
  • 8. [服务端] 解决桥接模式下MQ断线自动恢复时消费者Chennal未主动清理,导致channel越来越多的问题(无消费者与其关联的空channel):
  • 9. [Android] 提升targetSdkVersion至33(即Android 13);
  • 10. [Android] 升级开发工程使之支持最新Android Studio Giraffe和Gradle 8.1.1;

【最新版本源码地址】:

posted @ 2023-10-07 12:27 Jack Jiang 阅读(85) | 评论 (0)编辑 收藏

     摘要: 本文由字节教育-成人与创新前端团队分享,本文有修订和改动。1、引言作为开发人员,工作中我们可能会遇到以下问题:1)可能你知道 JavaScript 中 '😁'.length = 2,但 '👨👩👧👦'.length 呢?2)困惑于 Unicode 和 UTF-8 的关系?3)学计算机时会遇到这样的提问:一个汉字是几个字节?4)读取二进制数据时,为何有大端序小端序的分别?5)为何 UTF-8...  阅读全文

posted @ 2023-09-28 11:20 Jack Jiang 阅读(71) | 评论 (0)编辑 收藏

本文由阮一峰(ruanyifeng.com)分享,本文收录时有内容修订和排版优化。

1、引言

今天中午,我突然想搞清楚 Unicode 和 UTF-8 之间的关系,就开始查资料。

这个问题比我想象的复杂,午饭后一直看到晚上9点,才算初步搞清楚。

下面就是我的总结,主要用来整理自己的思路。我尽量写得通俗易懂,希望能对其他朋友有用。毕竟,字符编码是计算机技术的基石,对于程序员来说尤其重要,字符编码的知识是必须要懂的。

 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4433-1-1.html

2、专题目录

本文是“字符编码技术专题”系列文章的第 1 篇,总目录如下:

3、基础知识

计算机中储存的信息都是用二进制数表示的;而我们在屏幕上看到的英文、汉字等字符是二进制数转换之后的结果。通俗的说,按照何种规则将字符存储在计算机中,如'a'用什么表示,称为"编码";反之,将存储在计算机中的二进制数解析显示出来,称为"解码",如同密码学中的加密和解密。在解码过程中,如果使用了错误的解码规则,则导致'a'解析成'b'或者乱码。

字符集(Charset):是一个系统支持的所有抽象字符的集合。字符是各种文字和符号的总称,包括各国家文字、标点符号、图形符号、数字等。

字符编码(Character Encoding):是一套法则,使用该法则能够对自然语言的字符的一个集合(如字母表或音节表),与其他东西的一个集合(如号码或电脉冲)进行配对。即在符号集合与数字系统之间建立对应关系,它是信息处理的一项*本技术。通常人们用符号集合(一般情况下就是文字)来表达信息。而以计算机为*础的信息处理系统则是利用元件(硬件)不同状态的组合来存储和处理信息的。元件不同状态的组合能代表数字系统的数字,因此字符编码就是将符号转换为计算机可以接受的数字系统的数,称为数字代码。

常见字符集名称:ASCII字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等。计算机要准确的处理各种字符集文字,需要进行字符编码,以便计算机能够识别和存储各种文字。

4、ASCII 码

我们知道,计算机内部,所有信息最终都是一个二进制值。每一个二进制位(bit)有0和1两种状态,因此八个二进制位就可以组合出256种状态,这被称为一个字节(byte)。也就是说,一个字节一共可以用来表示256种不同的状态,每一个状态对应一个符号,就是256个符号,从00000000到11111111。

上个世纪60年代,美国制定了一套字符编码,对英语字符与二进制位之间的关系,做了统一规定。这被称为 ASCII 码,一直沿用至今。

ASCII 码一共规定了128个字符的编码,比如空格SPACE是32(二进制00100000),大写的字母A是65(二进制01000001)。这128个符号(包括32个不能打印出来的控制符号),只占用了一个字节的后面7位,最前面的一位统一规定为0。

▲ ASCII编码表

5、非 ASCII 编码

英语用128个符号编码就够了,但是用来表示其他语言,128个符号是不够的。比如,在法语中,字母上方有注音符号,它就无法用 ASCII 码表示。于是,一些欧洲国家就决定,利用字节中闲置的最高位编入新的符号。比如,法语中的é的编码为130(二进制10000010)。这样一来,这些欧洲国家使用的编码体系,可以表示最多256个符号。

▲ 扩展ASCII编码表

但是,这里又出现了新的问题。不同的国家有不同的字母,因此,哪怕它们都使用256个符号的编码方式,代表的字母却不一样。比如,130在法语编码中代表了é,在希伯来语编码中却代表了字母Gimel (ג),在俄语编码中又会代表另一个符号。但是不管怎样,所有这些编码方式中,0--127表示的符号是一样的,不一样的只是128--255的这一段。

至于亚洲国家的文字,使用的符号就更多了,汉字就多达10万左右。一个字节只能表示256种符号,肯定是不够的,就必须使用多个字节表达一个符号。比如,简体中文常见的编码方式是 GB2312,使用两个字节表示一个汉字,所以理论上最多可以表示 256 x 256 = 65536 个符号。

中文编码的问题比较复杂,将在文末讨论。这里先了解下,虽然都是用多个字节表示一个符号,但是GB类的汉字编码与后文的 Unicode 和 UTF-8 是毫无关系的。

6、Unicode

正如上一节所说,世界上存在着多种编码方式,同一个二进制数字可以被解释成不同的符号。因此,要想打开一个文本文件,就必须知道它的编码方式,否则用错误的编码方式解读,就会出现乱码。为什么电子邮件常常出现乱码?就是因为发信人和收信人使用的编码方式不一样。

可以想象,如果有一种编码,将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码,那么乱码问题就会消失。这就是 Unicode,就像它的名字都表示的,这是一种所有符号的编码。

Unicode 当然是一个很大的集合,现在的规模可以容纳100多万个符号。每个符号的编码都不一样,比如,U+0639表示阿拉伯字母Ain,U+0041表示英语的大写字母A,U+4E25表示汉字严。具体的符号对应表,可以查询unicode.org,或者专门的汉字对应表

7、Unicode 的问题

需要注意的是,Unicode 只是一个符号集,它只规定了符号的二进制代码,却没有规定这个二进制代码应该如何存储。

比如,汉字严的 Unicode 是十六进制数4E25,转换成二进制数足足有15位(100111000100101),也就是说,这个符号的表示至少需要2个字节。表示其他更大的符号,可能需要3个字节或者4个字节,甚至更多。

这里就有两个严重的问题,第一个问题是,如何才能区别 Unicode 和 ASCII ?计算机怎么知道三个字节表示一个符号,而不是分别表示三个符号呢?第二个问题是,我们已经知道,英文字母只用一个字节表示就够了,如果 Unicode 统一规定,每个符号用三个或四个字节表示,那么每个英文字母前都必然有二到三个字节是0,这对于存储来说是极大的浪费,文本文件的大小会因此大出二三倍,这是无法接受的。

它们造成的结果是:1)出现了 Unicode 的多种存储方式,也就是说有许多种不同的二进制格式,可以用来表示 Unicode。2)Unicode 在很长一段时间内无法推广,直到互联网的出现。

8、UTF-8

互联网的普及,强烈要求出现一种统一的编码方式。UTF-8 就是在互联网上使用最广的一种 Unicode 的实现方式。其他实现方式还包括 UTF-16(字符用两个字节或四个字节表示)和 UTF-32(字符用四个字节表示),不过在互联网上*本不用。重复一遍,这里的关系是,UTF-8 是 Unicode 的实现方式之一。

UTF-8 最大的一个特点,就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号,根据不同的符号而变化字节长度。

UTF-8 的编码规则很简单,只有二条:

  • 1)对于单字节的符号:字节的第一位设为0,后面7位为这个符号的 Unicode 码。因此对于英语字母,UTF-8 编码和 ASCII 码是相同的;
  • 2)对于n字节的符号(n > 1):第一个字节的前n位都设为1,第n + 1位设为0,后面字节的前两位一律设为10。剩下的没有提及的二进制位,全部为这个符号的 Unicode 码。

下表总结了编码规则,字母x表示可用编码的位:

跟据上表,解读 UTF-8 编码非常简单。如果一个字节的第一位是0,则这个字节单独就是一个字符;如果第一位是1,则连续有多少个1,就表示当前字符占用多少个字节。

下面,还是以汉字严为例,演示如何实现 UTF-8 编码。

严的 Unicode 是4E25(100111000100101),根据上表,可以发现4E25处在第三行的范围内(0000 0800 - 0000 FFFF),因此严的 UTF-8 编码需要三个字节,即格式是1110xxxx 10xxxxxx 10xxxxxx。然后,从严的最后一个二进制位开始,依次从后向前填入格式中的x,多出的位补0。这样就得到了,严的 UTF-8 编码是11100100 10111000 10100101,转换成十六进制就是E4B8A5。

9、Unicode 与 UTF-8 之间的转换

通过上一节的例子,可以看到严的 Unicode码 是4E25,UTF-8 编码是E4B8A5,两者是不一样的。它们之间的转换可以通过程序实现。

Windows平台,有一个最简单的转化方法,就是使用内置的记事本小程序notepad.exe。打开文件后,点击文件菜单中的另存为命令,会跳出一个对话框,在最底部有一个编码的下拉条。

里面有四个选项:ANSI,Unicode,Unicode big endian和UTF-8

  • 1)ANSI是默认的编码方式:对于英文文件是ASCII编码,对于简体中文文件是GB2312编码(只针对 Windows 简体中文版,如果是繁体中文版会采用 Big5 码);
  • 2)Unicode编码这里指的是notepad.exe使用的 UCS-2 编码方式:即直接用两个字节存入字符的 Unicode 码,这个选项用的 little endian 格式;
  • 3)Unicode big endian编码与上一个选项相对应:我在下一节会解释 little endian 和 big endian 的涵义;
  • 4)UTF-8编码:也就是上一节谈到的编码方法。

选择完"编码方式"后,点击"保存"按钮,文件的编码方式就立刻转换好了。

10、Little endian 和 Big endian

上一节已经提到,UCS-2 格式可以存储 Unicode 码(码点不超过0xFFFF)。以汉字严为例,Unicode 码是4E25,需要用两个字节存储,一个字节是4E,另一个字节是25。存储的时候,4E在前,25在后,这就是 Big endian 方式;25在前,4E在后,这是 Little endian 方式。

这两个古怪的名称来自英国作家斯威夫特的《格列佛游记》。在该书中,小人国里爆发了内战,战争起因是人们争论,吃鸡蛋时究竟是从大头(Big-endian)敲开还是从小头(Little-endian)敲开。为了这件事情,前后爆发了六次战争,一个皇帝送了命,另一个皇帝丢了王位。

第一个字节在前,就是"大头方式"(Big endian),第二个字节在前就是"小头方式"(Little endian)。

那么很自然的,就会出现一个问题:计算机怎么知道某一个文件到底采用哪一种方式编码?

Unicode 规范定义,每一个文件的最前面分别加入一个表示编码顺序的字符,这个字符的名字叫做"零宽度非换行空格"(zero width no-break space),用FEFF表示。这正好是两个字节,而且FF比FE大1。

如果一个文本文件的头两个字节是FE FF,就表示该文件采用大头方式;如果头两个字节是FF FE,就表示该文件采用小头方式。

11、实例讲解

下面,举一个实例。

打开"记事本"程序notepad.exe,新建一个文本文件,内容就是一个严字,依次采用ANSI,Unicode,Unicode big endian和UTF-8编码方式保存。

然后,用文本编辑软件UltraEdit 中的"十六进制功能",观察该文件的内部编码方式:

  • 1)ANSI:文件的编码就是两个字节D1 CF,这正是严的 GB2312 编码,这也暗示 GB2312 是采用大头方式存储的。
  • 2)Unicode:编码是四个字节FF FE 25 4E,其中FF FE表明是小头方式存储,真正的编码是4E25。
  • 3)Unicode big endian:编码是四个字节FE FF 4E 25,其中FE FF表明是大头方式存储。
  • 4)UTF-8:编码是六个字节EF BB BF E4 B8 A5,前三个字节EF BB BF表示这是UTF-8编码,后三个E4B8A5就是严的具体编码,它的存储顺序与编码顺序是一致的。

UltraEdit下载地址请至官网:https://www.ultraedit.com/

▲ UltraEdit软件

12、最后简要看看中文字符集和编码

12.1GB系列字符集&编码

计算机发明之处及后面很长一段时间,只用应用于美国及西方一些发达国家,ASCII能够很好满足用户的需求。但是当天朝也有了计算机之后,为了显示中文,必须设计一套编码规则用于将汉字转换为计算机可以接受的数字系统的数。

天朝专家把那些127号之后的奇异符号们(即EASCII)取消掉,规定:一个小于127的字符的意义与原来相同,但两个大于127的字符连在一起时,就表示一个汉字,前面的一个字节(他称之为高字节)从0xA1用到 0xF7,后面一个字节(低字节)从0xA1到0xFE,这样我们就可以组合出大约7000多个简体汉字了。在这些编码里,还把数学符号、罗马希腊的 字母、日文的假名们都编进去了,连在ASCII里本来就有的数字、标点、字母都统统重新编了两个字节长的编码,这就是常说的"全角"字符,而原来在127号以下的那些就叫"半角"字符了。

上述编码规则就是GB2312。GB2312或GB2312-80是中国国家标准简体中文字符集,全称《信息交换用汉字编码字符集·*本集》,又称GB0,由中国国家标准总局发布,1981年5月1日实施。GB2312编码通行于中国大陆;新加坡等地也采用此编码。中国大陆几乎所有的中文系统和国际化的软件都支持GB2312。GB2312的出现,*本满足了汉字的计算机处理需要,它所收录的汉字已经覆盖中国大陆99.75%的使用频率。对于人名、古汉语等方面出现的罕用字,GB2312不能处理,这导致了后来GBK及GB 18030汉字字符集的出现。下图是GB2312编码的开始部分(由于其非常庞大,只列举开始部分,具体可查看GB2312简体中文编码表)。

▲ GB2312编码表的开始部分

由于GB 2312-80只收录6763个汉字,有不少汉字,如部分在GB 2312-80推出以后才简化的汉字(如"啰"),部分人名用字(如中国前总理***的"*"字),台湾及香港使用的繁体字,日语及朝鲜语汉字等,并未有收录在内。于是厂商微软利用GB 2312-80未使用的编码空间,收录GB 13000.1-93全部字符制定了GBK编码。根据微软资料,GBK是对GB2312-80的扩展,也就是CP936字码表 (Code Page 936)的扩展(之前CP936和GB 2312-80一模一样),最早实现于Windows 95简体中文版。虽然GBK收录GB 13000.1-93的全部字符,但编码方式并不相同。GBK自身并非国家标准,只是曾由国家技术监督局标准化司、电子工业部科技与质量监督司公布为"技术规范指导性文件"。原始GB13000一直未被业界采用,后续国家标准GB18030技术上兼容GBK而非GB13000。

GB 18030,全称:国家标准GB 18030-2005《信息技术 中文编码字符集》,是中华人民共和国现时最新的内码字集,是GB 18030-2000《信息技术 信息交换用汉字编码字符集 *本集的扩充》的修订版。与GB 2312-1980完全兼容,与GBK*本兼容,支持GB 13000及Unicode的全部统一汉字,共收录汉字70244个。

GB 18030主要有以下特点:

  • 与UTF-8相同,采用多字节编码,每个字可以由1个、2个或4个字节组成;
  • 编码空间庞大,最多可定义161万个字符;
  • 支持中国国内少数民族的文字,不需要动用造字区;
  • 汉字收录范围包含繁体汉字以及日韩汉字。

▲ GB18030编码总体结构

本规格的初版使中华人民共和国信息产业部电子工业标准化研究所起草,由国家质量技术监督局于2000年3月17日发布。现行版本为国家质量监督检验总局和中国国家标准化管理委员会于2005年11月8日发布,2006年5月1日实施。此规格为在中国境内所有软件产品支持的强制规格。

12.2BIG5字符集&编码

Big5,又称为大五码或五大码,是使用繁体中文(正体中文)社区中最常用的电脑汉字字符集标准,共收录13,060个汉字。中文码分为内码及交换码两类,Big5属中文内码,知名的中文交换码有CCCII、CNS11643。Big5虽普及于台湾、香港与澳门等繁体中文通行区,但长期以来并非当地的国家标准,而只是业界标准。倚天中文系统、Windows等主要系统的字符集都是以Big5为*准,但厂商又各自增加不同的造字与造字区,派生成多种不同版本。2003年,Big5被收录到CNS11643中文标准交换码的附录当中,取得了较正式的地位。这个最新版本被称为Big5-2003。

Big5码是一套双字节字符集,使用了双八码存储方法,以两个字节来安放一个字。第一个字节称为"高位字节",第二个字节称为"低位字节"。"高位字节"使用了0x81-0xFE,"低位字节"使用了0x40-0x7E,及0xA1-0xFE。

有关Big5的更多技术细节读者可单独深入研究,本文就不赘述了。

13、本文小结

这些字符集和编码的关系很容易让程序员混淆,现在小结一下。

简单来说:Unicode、GBK和Big5码等就是编码的值(也就是术语“字符集”),而UTF-8、UTF-16、UTF32之类就是这个值的表现形式(即术语“编码格式”)。

另外:Unicode、GBK和Big5码等字符集是不兼容的,同一个汉字在这三个字符集里的码值是完全不一样的。如"汉"的Unicode值与gbk就是不一样的,假设Unicode为a040,GBK为b030。以UTF-8为例,UTF-8码完全只针对Unicode来组织的,如果GBK要转UTF-8必须先转Unicode码,再转UTF-8就OK了。

即GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换:

1)GBK、GB2312 --先转--> Unicode --再转--> UTF8

2)UTF8 --先转--> Unicode --再转--> GBK、GB2312

附录:更多IM技术精华文章

[1] 新手入门一篇就够:从零开发移动端IM

[2] 零*础IM开发入门(一):什么是IM系统?

[3] 零*础IM开发入门(二):什么是IM系统的实时性?

[4] 零*础IM开发入门(三):什么是IM系统的可靠性?

[5] 零*础IM开发入门(四):什么是IM系统的消息时序一致性?

[6] 移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

[7] 移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

[8] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[9] 现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

[10] 史上最通俗Netty框架入门长文:*本介绍、环境搭建、动手实战

[11] 强列建议将Protobuf作为你的即时通讯应用数据传输格式

[12] IM通讯协议专题学习(一):Protobuf从入门到精通,一篇就够!

[13] 微信新一代通信安全解决方案:*于TLS1.3的MMTLS详解

[14] 探讨组合加密算法在IM中的应用

[15] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制

[16] IM消息送达保证机制实现(一):保证在线实时消息的可靠投递

[17] 理解IM消息“可靠性”和“一致性”问题,以及解决方案探讨

[18] 融云技术分享:全面揭秘亿级IM消息的可靠投递机制

[19] IM群聊消息如此复杂,如何保证不丢不重?

[20] 零*础IM开发入门(四):什么是IM系统的消息时序一致性?

[21] 一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等

[22] 如何保证IM实时消息的“时序性”与“一致性”?

[23] 阿里IM技术分享(六):闲鱼亿级IM消息系统的离线推送到达率优化

[24] 微信的海量IM聊天消息序列号生成实践(算法原理篇)

[25] 社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等

[26] 网易云信技术分享:IM中的万人群聊技术方案实践总结

[27] 企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等

[28] 融云IM技术分享:万人群聊消息投递方案的思考和实践

[29] 为何*于TCP协议的移动端IM仍然需要心跳保活机制?

[30] 一文读懂即时通讯应用中的网络心跳包机制:作用、原理、实现思路等

[31] 微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)

[32] 融云技术分享:融云安卓端IM产品的网络链路保活技术实践

[33] 阿里IM技术分享(九):深度揭密RocketMQ在钉钉IM系统中的应用实践

[34] 彻底搞懂TCP协议层的KeepAlive保活机制

[35] 深度解密钉钉即时消息服务DTIM的技术设计

[36] *于实践:一套百万消息量小规模IM系统技术要点总结

[37] 跟着源码学IM(十):*于Netty,搭建高性能IM集群(含技术思路+源码)

[38] 一套十万级TPS的IM综合消息系统的架构实践与思考


(本文已同步发布于:http://www.52im.net/thread-4433-1-1.html

posted @ 2023-09-27 10:36 Jack Jiang 阅读(57) | 评论 (0)编辑 收藏

     摘要: 本文由腾讯WXG客户端开发工程师yecong分享,本文做了修订和改动。1、引言相对于传统的消费级IM应用,企业级IM应用的特殊之外在于它的用户关系是按照所属企业的组织架构来关联的起来,而组织架构的大小是无法预设上限的,这也要求企业级IM应用在遇到真正的超大规模组织架构时,如何保证它的应用性能不受限于(或者说是尽可能不受限于)企业架构规模,这是个比较有难度的技术问题。本文主要分享的是企业微信在百对百...  阅读全文

posted @ 2023-09-21 11:15 Jack Jiang 阅读(68) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第21 期。

[- 1 -] 新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践

[链接http://www.52im.net/thread-2007-1-1.html

[摘要] 本文我们就来聊聊分布式架构的演进过程,希望能给大家带来眼前一亮的感觉。


[- 2 -] 一篇读懂分布式架构下的负载均衡技术:分类、原理、算法、常见方案等

[链接http://www.52im.net/thread-2494-1-1.html

[摘要] 本文将从负载均衡技术的分类、技术原理、常见实现算法、常用方案等入手,为您详细讲解负载均衡技术的方方面面。这其中,四层和七层负载均衡技术最为常用,它们也是本文介绍的重点。


[- 3 -] 从新手到架构师,一篇就够:从100到1000万高并发的架构演进之路

[链接http://www.52im.net/thread-2665-1-1.html

[摘要] 本文以设计淘宝网的后台架构为例,介绍从一百个并发到千万级并发情况下服务端的架构的14次演进过程,同时列举出每个演进阶段会遇到的相关技术,让大家对架构的演进有一个整体的认知。


[- 4 -] 腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面

[链接http://www.52im.net/thread-1811-1-1.html

[摘要] 本文结合作者多年的互联网系统设计实践经验,从最基本的技术概念开始,带你探寻服务器端系统架构的方方面面。


[- 5 -] 快速理解高性能HTTP服务端的负载均衡技术原理

[链接http://www.52im.net/thread-1950-1-1.html

[摘要] 本文将以简洁通俗的文字,为你讲解主流的HTTP服务端实现负载均衡的常见方案,以及具体到方案中的负载均衡算法的实现原理。理解和掌握这些方案、算法原理,有助于您今后的互联网项的技术选型和架构设计,因为没有哪一种方案和算法能解决所有问题,只有针对特定的场景使用合适的方案和算法才是最明智的选择。


[- 6 -] 知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路

[链接http://www.52im.net/thread-1968-1-1.html

[摘要] 本文作者陈鹏是该系统的负责人,本次文章深入介绍了该系统的方方面面,值得互联网后端程序员仔细研究。


[- 7 -] 阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史

[链接http://www.52im.net/thread-2050-1-1.html

[摘要] 阿里数据库事业部研究员张瑞,将为你讲述双11数据库技术不为人知的故事。在零点交易数字一次次提升的背后,既是数据库技术的一次次突破,也见证了阿里技术人永不言败的精神,每一次化“不可能”为“可能”的过程都是阿里技术人对技术的不懈追求。


[- 8 -]  阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路

[链接http://www.52im.net/thread-2072-1-1.html

[摘要] OceanBase 是蚂蚁金服自研的分布式数据库,在其 9 年的发展历程里,从艰难上线到找不到业务场景濒临解散,最后在双十一的流量考验下浴火重生,成为蚂蚁金服全部核心系统的承载数据库。这一路走来的艰辛和故事,蚂蚁金服高级研究员、OceanBase 团队负责人阳振坤将为你娓娓道来。


[- 9 -] 达达O2O后台架构演进实践:从0到4000高并发请求背后的努力

[链接http://www.52im.net/thread-2141-1-1.html

[摘要] 达达的业务组成简单直接——商家下单、配送员接单和配送,也正因为理解起来简单,使得达达的业务量在短时间能实现爆发式增长。而支撑业务快速增长的背后,正是达达技术团队持续不断的快速技术迭代的结果,本文正好借此机会,总结并分享了这一系列技术演进的第一手实践资料,希望能给同样奋斗在互联网创业一线的你带来启发。


[- 10 -] 优秀后端架构师必会知识:史上最全MySQL大表优化方案总结

[链接http://www.52im.net/thread-2157-1-1.html

[摘要] 本文将总结和分享当MySQL单表记录数过大时,增删改查性能急剧下降问题的优化思路,这也是资深后端架构师、程序员所必备的知识内容之一,希望本文对你有用。


[- 11 -] 通俗易懂:如何设计能支撑百万并发的数据库架构?

[链接http://www.52im.net/thread-2510-1-1.html

[摘要] 本篇文章我们一起来学习一下,对于一个支撑日活百万用户的高并发系统,数据库架构应该如何设计呢?


[- 12 -] 多维度对比5款主流分布式MQ消息队列,妈妈再也不担心我的技术选型了

[链接http://www.52im.net/thread-2625-1-1.html

[摘要] 本文将从17个维度综合对比Kafka、RabbitMQ、ZeroMQ、RocketMQ、ActiveMQ这5款当前最主流的MQ消息中间件产品,希望能为您的下一次产品的架构设计和MQ消息中间件选型提供参考依据。


[- 13 -] 小米技术分享:解密小米抢购系统千万高并发架构的演进和实践

[链接http://www.52im.net/thread-2323-1-1.html

[摘要] 本次分享将为大家解密该系统的技术演进、设计思路、实践总结等,希望能带给您启发。


[- 14 -] 美团技术分享:深度解密美团的分布式ID生成算法

[链接http://www.52im.net/thread-2751-1-1.html

[摘要] 对于美团的Leaf-segment这个ID生成方案,因为生成的ID全局唯一、全局有序,所以非常适合IM这种应用场景,这也是即时通讯网整理并分享给社区的原因。


[- 15 -] 12306抢票带来的启示:看我如何用Go实现百万QPS的秒杀系统(含源码)

[链接http://www.52im.net/thread-2771-1-1.html

[摘要] 本文内容虽是从秒杀系统谈起,并未直接涉及即时通讯相关知识,但有关Go的高并发实践,仍然值得广大即时通讯网的技术爱好者们研究和学习,必竟业务可以不同,但技术都是相通的,或许能为你即时通讯系统的高并发架构带来新的思路和灵感。


👉52im社区本周新文:《企业微信针对百万级组织架构的客户端性能优化实践 http://www.52im.net/thread-4437-1-1.html》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-09-20 12:31 Jack Jiang 阅读(57) | 评论 (0)编辑 收藏

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅支持UDP 、TCP 、WebSocket 三种协议,支持iOS、Android、H5、标准Java平台,服务端基于Netty编写。

工程开源地址是:

关于RainbowChat

► 详细产品介绍:http://www.52im.net/thread-19-1-1.html
► 版本更新记录:http://www.52im.net/thread-1217-1-1.html
► 全部运行截图:Android端iOS端
► 在线体验下载:专业版(TCP协议)专业版(UDP协议)      (关于 iOS 端,请:点此查看

 

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题(可自行下载体验:专业版下载安装)。

* RainbowChat可能是市面上提供im即时通讯聊天源码的,唯一一款同时支持TCP、UDP两种通信协议的IM产品(通信层基于开源IM聊天框架  MobileIMSDK 实现)。

v10.0 版更新内容

此版更新内容更多历史更新日志):

(1)Android端主要更新内容新增群名片、消息转发功能等】:

  • 1)[新增] 新增发送“群名片”消息功能;
  • 2)[新增] 新增了消息转发功能;
  • 3)[新增] 新增了实时音视频聊天记录的功能;
  • 4)[bug] 解决了加载离线消息可能导致首页“消息”列表出现重复item的问题;
  • 5)[优化] 修正了实时语音聊天呼叫ui上的提示文字错误;
  • 6)[优化] 取消了实时音视频聊天必须对方在线才能呼叫的限制;
  • 7)[优化] 安全提升,优化了http接口、文件上传接口、socket长连接的token校验逻辑;
  • 8)[优化] 更换了新的高德地图WebSevice key;
  • 9)[优化] 其它ui细节优化等。

(2)服务端主要更新内容:

  • 1)[新增] 安全提升,实现了一套新的token生成、校验机制(支持对称加密和非对称加密两种模式);
  • 2)[新增] 安全提升,启用了AppKey校验机制.

此版主要功能运行截图更多截图点此查看):

posted @ 2023-09-18 13:39 Jack Jiang 阅读(45) | 评论 (0)编辑 收藏

     摘要: 本文由QQ技术团队分享,本文收录时有内容修订和大量排版优化。1、引言QQ 作为国民级应用,从互联网兴起就一直陪伴着大家,是很多用户刚接触互联网就开始使用的应用。而 QQ 桌面版最近一次技术架构升级还是在移动互联网兴起之前,在多年迭代过程中,QQ 桌面版也积累了不少技术债务,随着业务的发展和技术的进步,当前的架构已经无法很好支撑对 QQ 的发展了。在 2022 年初,我们下定决心对 QQ 进行全面的...  阅读全文

posted @ 2023-09-14 10:30 Jack Jiang 阅读(91) | 评论 (0)编辑 收藏

为了更好地分类阅读 52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第20 期。

[-1-] 融云技术分享:全面揭秘亿级IM消息的可靠投递机制

[链接] http://www.52im.net/thread-3638-1-1.html

[摘要] 本文根据融云亿级IM消息系统的技术实践,总结了分布式IM消息的可靠投递机制,希望能为你的IM开发和知识学习起到抛砖引玉的作用。


 [--] IM开发技术学习:揭秘微信朋友圈这种信息推流背后的系统设计

[链接] http://www.52im.net/thread-3675-1-1.html

[摘要] 本文将重点讨论的是“关注”功能对应的技术实现:先总结常用的基于时间线Feed流的后台技术实现方案,再结合具体的业务场景,根据实际需求在基本设计思路上做一些灵活的运用。


 [--] 阿里IM技术分享(三):闲鱼亿级IM消息系统的架构演进之路

[链接] http://www.52im.net/thread-3699-1-1.html

[摘要] 本文分享的是闲鱼即时消息系统架构从零开始的技术变迁之路,以期更多的同行们在此基础上汲取经验,得到有价值的启发。


 [--] 阿里IM技术分享(四):闲鱼亿级IM消息系统的可靠投递优化实践

[链接] http://www.52im.net/thread-3706-1-1.html

[摘要] 那么基于闲鱼现有的即时消息系统架构和技术体系,如何来优化它的消息稳定性、可靠性?应该从哪里开始治理?当前系统现状到底是什么样?如何客观进行衡量?希望本文能让大家看到一个不一样的闲鱼即时消息系统。


 [--] 阿里IM技术分享(五):闲鱼亿级IM消息系统的及时性优化实践

[链接] http://www.52im.net/thread-3726-1-1.html

[摘要] 本文将根据闲鱼IM消息系统在消息及时性方面的优化实践,详细分析了IM在线通道面临的各种技术问题,并通过相应的技术手段来优化从而保证用户消息的及时到达。


 [- 6 -] 阿里IM技术分享(六):闲鱼亿级IM消息系统的离线推送到达率优化

[链接] http://www.52im.net/thread-3748-1-1.html

[摘要] 本文将要分享的是闲鱼IM消息在解决离线推送的到达率方面的技术实践,内容包括问题分析和技术优化思路等,希望能带给你启发。


 [-7-] 阿里IM技术分享(八):深度解密钉钉即时消息服务DTIM的技术设计

[链接] http://www.52im.net/thread-4012-1-1.html

[摘要] 本篇文章内容将从模型设计原理到具体的技术架构、最底层的存储模型到跨地域的单元化等,全方位展现了 DTIM 在实际生产应用中所遇到的各种技术挑战及相应的解决方案,希望借本文内容的分享能为国内企业级IM的开发带来思考和启发。


 [-8 -]  阿里IM技术分享(九):深度揭密RocketMQ在钉钉IM系统中的应用实践

[链接] http://www.52im.net/thread-4106-1-1.html

[摘要] 在钉钉的IM中,我们通过 RocketMQ实现了系统解耦、异步削峰填谷,还通过定时消息实现分布式定时任务等高级特性。同时与 RocketMQ 深入共创,不断优化解决了很多RocketMQ本身的问题,并且孵化出 POP 消费模式等新特性,使 RocketMQ 能够完美支持对性能稳定性和时延要求非常高的 IM 系统。本文将为你分享这些内容。


 [--] 基于实践:一套百万消息量小规模IM系统技术要点总结

[链接] http://www.52im.net/thread-3752-1-1.html

[摘要] 本文内容将从开发者的视角出发(主要是我自已的开发体会),围绕项目背景、业务需求、技术原理、开发方案等主题,一步一步的与大家一起剖析:设计一套百万消息量的小规模IM系统架构设计上需要注意的技术要点。


 [-10 -] 跟着源码学IM(十):基于Netty,搭建高性能IM集群(含技术思路+源码)

[链接] http://www.52im.net/thread-3816-1-1.html

[摘要] 本文将根据笔者这次的业余技术实践,为你讲述如何基于Netty+Zk+Redis来搭建一套高性能IM集群,包括本次实现IM集群的技术原理和实例代码,希望能带给你启发。


 [-11 -] 一套十万级TPS的IM综合消息系统的架构实践与思考

[链接] http://www.52im.net/thread-3954-1-1.html

[摘要] 下面就由我来介绍一下我所负责的公司IM综合消息系统所经历的架构设计历程,以及架构设计过程中的一些思路和总结,希望能给你带来启发。


 [-12 -]  直播系统聊天技术(八):vivo直播系统中IM消息模块的架构实践

[链接] http://www.52im.net/thread-3994-1-1.html

[摘要] 本文针对秀场直播,结合我们一年以来通过处理不同的业务线上问题,进行了技术演进式的IM消息模块架构的升级与调整,并据此进行了技术总结、整理成文,希望借此机会分享给大家。


 [-13-] 得物从0到1自研客服IM系统的技术实践之路

[链接] http://www.52im.net/thread-4153-1-1.html

[摘要] 本篇文章将基于工程实践,分享我们从0到1自研一套客服IM系统时在各种关键技术点上的设计思路和实践方法。


 [-14-] 海量用户IM聊天室的架构设计与实践

[链接] http://www.52im.net/thread-4404-1-1.html

[摘要] 本文将分享网易云信针对海量用户IM聊天室的架构设计与应用实践,希望能带给你启发。


👉52im社区本周新文:《IM跨平台技术学习(九):全面解密新QQ桌面版的Electron内存优化实践 http://www.52im.net/thread-4429-1-1.html》,欢迎阅读!👈

我是Jack Jiang,我为自已带盐!https://github.com/JackJiang2011/MobileIMSDK/

posted @ 2023-09-13 11:22 Jack Jiang 阅读(68) | 评论 (0)编辑 收藏

本文由vivo 互联网服务器团队Yu Quan分享,本文收录时有内容修订和重新排版。

1、引言

如今,Android端的即时通讯IM这类应用想实现离线消息推送,难度越来越大(详见《Android P正式版即将到来:后台应用保活、消息推送的真正噩梦》、《Android保活从入门到放弃:乖乖引导用户加白名单吧》)。

于是,使用手机厂商自建的ROOM级消息推送通道进行IM离线消息推送是个不得不面对的问题,我们也正好借此文机会,一窥主流手机厂商的ROOM级推送通道的技术实现吧。

vivo手机的厂商级消息推送系统的现状是最高推送速度140w/s,单日最大消息量200亿,端到端秒级在线送达率99.9%。同时推送系统具备不可提前预知的突发大流量特点。

本文将要分享的是vivo技术团队针对消息推送系统的高并发、高时效、突发流量等特点,从长连接层容灾、逻辑层容灾、流量容灾、存储容灾等方面入手,如何保证百亿级厂商消息推送平台的高可用性的。

* 推荐阅读:vivo技术团队分享的另一篇消息推送技术文章《vivo手机上的系统级消息推送平台的架构设计实践》。

 
技术交流:

(本文已同步发布于:http://www.52im.net/thread-4416-1-1.html

2、推送系统介绍

vivo推送平台是vivo公司向开发者提供的消息推送服务,通过在云端与客户端之间建立一条稳定、可靠的长连接,为开发者提供向客户端应用实时推送消息的服务,支持百亿级的通知/消息推送,秒级触达移动用户。

推送系统主要由3部分组成:

  • 1)接入网关;
  • 2)逻辑推送节点;
  • 3)长连接。

其中,长连接负责与用户手机终端建立连接,及时把消息送达到手机终端。

推送系统的特点是:

  • 1)并发高;
  • 2)消息量大;
  • 3)送达及时性较高。

下面将针对这几个方面来分享我们的技术实践。

3、长连接层容灾的技术实现

长连接是推送系统最重要的部分,长连接的稳定性直接决定了推送系统的推送质量和性能。因此,需要对长连接层做好容灾和实时调度能力。

3.1面临的问题

原有推送系统架构是长连接层都部署在华东,所有vivo IDC逻辑节点通过VPC与华东的Broker建立连接,手机端跟华东的broker进行长连接通信。

这种部署方式存在以下问题。

1)问题一:华北、华南手机都需要连接华东的Broker,地域跨度大,长连接网络稳定性和时效性相对较差。

2)问题二:逻辑层跟华东的Broker之间由一条VPC连接,随着业务的发展,推送流量越来越大,带宽会出现瓶颈,有超限丢包的风险。另外当该VPC出现故障时,会造成全网消息无法送达。

注:长连接层节点名为Broker。

原始长连接架构图:

3.2解决方法

基于以上架构存在问题,我们对架构进行了优化。即将Broker进行三地部署,分别部署在华北、华东、华南。

华北、华东、华南三地用户采用就近接入方式。

优化后的架构,不仅可以保证长连接网络稳定性和时效性。同时具有较强的容灾能力,华东、华南Broker通过云网跟华北Broker连接,华北Broker通过VPC与vivo IDC连接。当华北、华东、华南某个地区Broker集群故障或者公网故障,不会影响到全网设备收发消息。

三地部署后的架构图:

3.3进一步优化

但是上述这种方式还是存在一个问题,就是某个地区Broker集群故障或者公网故障,会出现该区域部分设备无法收到推送消息的情况。

针对上述单个地区异常导致该区域部分设备无法收到推送消息的问题,我们设计了一套流量调度系统,可以做到实时流量调度和切换。global scheduler节点负责策略调度和管理。

vivo phone进行注册时:dispatcher会下发多个地区的ip地址,默认情况下,进行就近连接。单多次连接失败后,尝试连接其他ip。当某个地区Broker出现长连接数瓶颈或者VPC出现故障,可以通过global scheduler节点下发策略,让该故障地区的设备重新从dispatcher获取新的ip集的ip,与其他地区Broker建立长连接,逻辑节点下发消息到重连后的Broker。等到该地区恢复后,可以重新再下发策略,进行回调。

流量调度系统图:

4、逻辑层容灾的技术实现

长连接层做好容灾后,逻辑层也需要做相应容灾。

之前我们逻辑层都部署在一个机房,不具备机房间容灾能力,当一个机房出现断电风险,会出现服务整体不可用问题,因此我们做"同城双活"部署方案改造。

逻辑层单活架构:

逻辑层分别在vivo IDC1和vivo IDC2进行部署,网关层根据路由规则将流量按照一定比例分别下发到两个IDC,实现逻辑层同城双活。

我们发现:数据中心还是只有一个,部署在vivo IDC1,根据成本、收益,以及多数据中心数据同步延迟问题综合考虑,数据中心暂时还是以单数据中心为主。

逻辑层双活架构: