Z更好地分c阅?52im.net 总计1000多篇_文章Q我在每周三推送新的一期技术文集，本次是第26 期?/p>
[- 1 -] 实时语音聊天中的音频处理与编码压~技术简q?/span>
[链接] http://www.52im.net/thread-825-1-1.html
[摘要] 在视频或者音频通话q程中，一斚wZ减小原始声音数据的传输码率，需要进行音频压~，另一斚wZ得到更高质量的音质，需要进行音频处理。如何处理好q两斚wQ保证声音传播的高真性，是个技术活儿！
[- 2 -] |易视频云技术分享：音频处理与压~技术快速入?/span>
[链接] http://www.52im.net/thread-678-1-1.html
[摘要] 随着音频处理和压~技术的不断发展Q效果更好、适用范围更广、性能更高的算法和新的技术必不断涌玎ͼ不断改善我们的生zR?/p>
[- 3 -] 学习RFC3550QRTP/RTCP实时传输协议基础知识
[链接] http://www.52im.net/thread-590-1-1.html
[摘要] 本文对这些协议进行初步归UxȝQ在分析RFC3550的基上，重点分析RTPpd协议Qƈ以报文类型ؓȝ分析RTCPpd协议?/p>
[- 4 -]ZRTMP数据传输协议的实时流媒体技术研IӞ论文全文Q?/span>
[链接] http://www.52im.net/thread-273-1-1.html
[摘要] 本文来自论文《基?RTMP 协议的流媒体技术的原理与应用》，文中研究了基?Flash q_的流媒体pȝ中用的 RTMP 协议的原理和应用Qƈ对网l上实时媒体的各种传输方式的优~点q行了分析?/p>
[- 5 -] 声网架构师谈实时韌频云的实现难?视频采访)
[链接] http://www.52im.net/thread-399-1-1.html
[摘要] 孙雨润，声网 Agora.io 首席韌频架构师Q负责全球音视频传输技术架构。毕业于中国U学技术大学，?YY 后台架构师，d Web YY 整体后台pȝ架构搭徏。曾任职腾讯 QQ 研究?Q主?QQ I间面孔墙等目QQ职微?Microsoft 期间Q参与高性能计算产品目?/p>
[- 6 -] q在?#8220;喂喂?#8221;试实时语音通话质量Q本文教你科学的评测ҎQ?/span>
[链接] http://www.52im.net/thread-507-1-1.html
[摘要] 实时语音聊天开发，对于一般的开发者来说比较神U，很多朋友不太清楚如何全面的评C个音频引擎?/p>
[- 7 -] 如何用最单的Ҏ试你的实时韌频方?/span>
[链接] http://www.52im.net/thread-535-1-1.html
[摘要] 本文ȝ了一些有兛_旉视频Ҏ比较值得自测的要点，旨在没有生环境反馈和丰富的试资源情况下，用较低的成本来测试覆盖尽可能多的真实场景中可能遇到的|络和设备问题?/p>
[- 8 -] q实旉视频聊天中端到端加密QE2EEQ的工作原理
[链接] http://www.52im.net/thread-763-1-1.html
[摘要] 本文着重阐q端到端加密(E2EE)Q端到端加密是确保数据传输安全的可行Ҏ之一。读完这文章，你可以了解这U加密方式的基本原理.
[- 9 -] 理论联系实际Q实C个简单地ZHTML5的实时视频直?/span>
[链接] http://www.52im.net/thread-875-1-1.html
[摘要] 本次分n向大家介绍一下分享一下直播的整个程和一些技术点Qƈ动手实现一个简单的Demo?/p>
[- 10 -] IM实时韌频聊天时的回声消除技术详?/span>
[链接] http://www.52im.net/thread-939-1-1.html
[摘要] Z不让文章读v来枯燥，本文尽量通俗易懂Cؓ您讲解实旉视频聊天场景下的回声消除技术原因希望能带给你些许启发?/p>
[- 11 -] 如何优化传输机制来实现实旉视频的超低gq？
[链接] http://www.52im.net/thread-1008-1-1.html
[摘要] 要在语音视频 SDK 中实现超低gq，实时的语韌频传输机制是必不可少的，?FEC ?ARQ 的智能结合是实时语音视频传输机制的基矟?/p>
[- 12 -] 实时通信RTC技术栈之：视频~解?/span>
[链接] http://www.52im.net/thread-1034-1-1.html
[摘要] 本文是系列文章的W一：讲述视频~解码的一些基本知识?/p>
[- 13 -] Android直播入门实践Q动手搭Z套简单的直播pȝ
[链接] http://www.52im.net/thread-1154-1-1.html
[摘要] 实时视频直播是这两年非常火的技术Ş态，已经渗透到教育、在U互q各种业务场景中。但要搭Z套实时视频直播系l，q易事Q当然相关的直播技术理论在论坛的其它文章里已经写的非常详细Q本文不再展开?/p>
[- 14 -] |易云信实时视频直播在TCP数据传输层的一些优化思\
[链接] http://www.52im.net/thread-1254-1-1.html
[摘要] |易云信的实时视频直播目前用了TCPq行传输Q且Z此，从编码动态适配、发送队列调整、协议优化、socket{做了全程的优化，保在限带宽、丢包、时延、抖动，无论单项q是复杂|络Q都有非怸错的实际体验?/p>
[- 15 -] 实时韌频聊天技术分享：面向不可靠网l的抗丢包编解码?/span>
[链接] http://www.52im.net/thread-1281-1-1.html
[摘要] ~解码器面向直播和网l通信是不一LQ我今天惌的是面向不可靠传输网l的抗丢包编解码器?/p>
[- 16 -] P2P技术如何将实时视频直播带宽降低75%Q?/span>
[链接] http://www.52im.net/thread-1289-1-1.html
[摘要] 那整个系l是怎么设计的？使用了哪些技术来达成目标Q接下来我来重点分n一下架构设计和技术细节?/p>
👉52imC本周新文Q?a target="_blank" rel="noopener" style="color: #1d58d1; text-decoration-line: none;">抖音技术分享：抖音Android端手机功耗问题的全面分析和详l优化实?/a>》，Ƣ迎阅读Q?/p>
我是Jack JiangQ我已带盐！https://github.com/JackJiang2011/MobileIMSDK/
理订单状态，该上状态机吗？轻量U状态机COLA StateMachine保姆U入门教E?nbsp;
https://www.cnblogs.com/rude3knife/p/cola-statemachine.html
Spring-statemachine有限状态机(FSM)使用教程详解
https://blog.csdn.net/ZYC88888/article/details/112793317
https://github.com/alibaba/COLA/blob/master/cola-components/cola-component-statemachine/src/test/java/com/alibaba/cola/test/StateMachineChoiceTest.java
]]>
我能惛_的有q几点：
互联|业?strong style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important; color: black; visibility: visible;">q代?/strong>Q工期紧Q导?strong style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important; color: black; visibility: visible;">代码l构混ؕQ几乎没有代码注释和文?/section> 互联|?strong style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important; color: black; visibility: visible;">人员变动频繁Q很Ҏ接手别h的老项目，ChҎ没时间吃透代码结?/strong>Q紧q的工期又只能让屎山堆大?/section> 多h一起开发，每个人的~码习惯不同Q工L代码各用个的Q业务命名也l常冲突Q媄响效率?/section> 大部分团队几?strong style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important; color: black; visibility: visible;">没有旉做代码重?/strong>QQ׃码腐烂?/section>
每当我们新启动一个代码仓库，都是信心满满Q结构整z。但是时间越往后，代码变得腐败不堪，技术债务来庞大?/p>
q种情况有解x案吗Q也是有的：
组内定期做代码重构Q解x术债务?/section> l内设计完善的应用架构，让代码的腐烂来得慢一些?strong style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important; color: black; visibility: visible;">Q当然很隑ց到完全不腐烂Q?/strong> 设计量单，让不同层U的开发都能快速看懂ƈ上手开?/strong>Q而不是在一堆复杂的没h看懂的代码上堆更多的屎山?/section>
而COLAQ我们今天的主角Q就是ؓ了提?strong style="margin: 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important; visibility: visible;">一个可落地的业务代码结构规?/strong>Q让你的代码腐烂的尽可能慢一些，让团队的开发效率尽可能快一些?br />
https://github.com/alibaba/COLAhttps://blog.csdn.net/significantfrank/article/details/110934799
]]>
Z更好地分c阅?52im.net 总计1000多篇_文章Q我在每周三推送新的一期技术文集，本次是第25 期?/p>
[- 1 -] x通讯韌频开发（一Q：视频~解码之理论概述
[链接] http://www.52im.net/thread-228-1-1.html
[摘要] 本文主要讲解实时韌频技术中视频技术的~解码基理论?/p>
[- 2 -] x通讯韌频开发（二）Q视频编解码之数字视频介l?/span>
[链接] http://www.52im.net/thread-229-1-1.html
[摘要] 本文主要讲解实时韌频技术中视频技术的数字视频知识?/p>
[- 3 -] x通讯韌频开发（三）Q视频编解码之编码基
[链接] http://www.52im.net/thread-232-1-1.html
[摘要] 本文主要讲解实时韌频技术中视频技术的~码理论知识?/p>
[- 4 -] x通讯韌频开发（四）Q视频编解码之预技术介l?/span>
[链接] http://www.52im.net/thread-235-1-1.html
[摘要] 本文主要讲解实时韌频技术中视频技术的预测技术理论知识?/p>
[- 5 -] x通讯韌频开发（五）Q认识主视频编码技术H.264
[链接] http://www.52im.net/thread-237-1-1.html
[摘要] 本文主要讲解实时韌频技术中目前L的视频编码技术H.264相关知识?/p>
[- 6 -] x通讯韌频开发（六）Q如何开始音频编解码技术的学习
[链接] http://www.52im.net/thread-241-1-1.html
[摘要] 本文是一讲q新手如何学习音频编解码知识的文章?/p>
[- 7 -] x通讯韌频开发（七）Q音频基及编码原理入?/span>
[链接] http://www.52im.net/thread-242-1-1.html
[摘要] 本文是一讲q基音频知识和编码原理的文章?/p>
[- 8 -] x通讯韌频开发（八）Q常见的实时语音通讯~码标准
[链接] http://www.52im.net/thread-243-1-1.html
[摘要] 本文是一讲q常用的实用音频通讯~码标准的文章?/p>
[- 9 -] x通讯韌频开发（九）Q实时语音通讯的回韛_回音消除概述
[链接] http://www.52im.net/thread-247-1-1.html
[摘要] 本文是一介l实旉频通讯q程中的回音问题Q以及回x除技术的介绍文章?/p>
[- 10 -] x通讯韌频开发（十）Q实时语音通讯的回x除技术详?/span>
[链接] http://www.52im.net/thread-250-1-1.html
[摘要] 本文是一详l介l实旉频通讯q程中的回音消除技术的文章Q主要描q的是回x除技术理论和法原理{?/p>
[- 11 -] x通讯韌频开发（十一Q：实时语音通讯丢包补偿技术详?/span>
[链接] http://www.52im.net/thread-251-1-1.html
[摘要] 本文是一详l介l实时语音通讯q程中的丢包补偿技术的文章?/p>
[- 12 -] x通讯韌频开发（十二Q：多h实时韌频聊天架构探?/span>
[链接] http://www.52im.net/thread-253-1-1.html
[摘要] 虽然都是视频通讯Q大部分情况下的单h视频通话可能Ҏ不需要用到流媒体服务Q而多频，如在U教育这些则必须用到Q所以下面主要介l多频中服务端架构模式，以及各自特点?/p>
[- 13 -] x通讯韌频开发（十三Q：实时视频~码H.264的特点与优势
[链接] http://www.52im.net/thread-266-1-1.html
[摘要] 本文主要讲解实时韌频技术中最行的视频编码技术H.264的特点和优势Q希望能为您的技术选型提供一定的参考?/p>
[- 14 -] x通讯韌频开发（十四Q：实时韌频数据传输协议介l?/span>
[链接] http://www.52im.net/thread-267-1-1.html
[摘要] 本文简要介l这些主的实时韌频数据传输协议?/p>
[- 15 -] x通讯韌频开发（十五Q：聊聊P2P与实旉视频的应用情?/span>
[链接] http://www.52im.net/thread-269-1-1.html
[摘要] p2p是点对点，两个客户端直接进行数据交互，不需要经q服务器转发(relay)Q这U方式能大大减轻服务端的负蝲Q所以特别视适合大数据的传输Q比如实旉视频聊天、在U视频直播、大文g传输{应用场景?/p>
[- 16 -] x通讯韌频开发（十六Q：Ud端实旉视频开发的几个
[链接] http://www.52im.net/thread-270-1-1.html
[摘要] 本文就几个典型问题l出要的参考徏议?/p>
[- 17 -] x通讯韌频开发（十七Q：视频~码H.264、VP8的前世今?/span>
[链接] http://www.52im.net/thread-274-1-1.html
[摘要] 本文重在者从技术角度讲解H.264和VP8的发展渊源以及现时所面的问题，怿d此文后，对于x通讯QIM聊天应用Q的实时韌频开发中视频~码的选择会有个直观的了解?/p>
[- 18 -] x通讯韌频开发（十八Q：详解音频~解码的原理、演q和应用选型
[链接] http://www.52im.net/thread-2230-1-1.html
[摘要] 以下是本次为大家分享的主要内容Q希望通过此次分n可以使大家对音频~解码有一个整体的认识Qƈ在实际应用中有参考的依据?/p>
[- 19 -] x通讯韌频开发（十九Q：零基Q史上最通俗视频~码技术入?/span>
[链接] http://www.52im.net/thread-2840-1-1.html
[摘要] 视频~码技术涉及的内容太过专业和庞杂，市面上的书籍或博客多数都只是枯燥的技术概늽列，对于新手来说d依旧蒙逼是常态，本文借此ZQ专门给大家做一个关于视频编码的零基U普?/p>
[- 20 -] x通讯韌频开发（二十Q：一文读懂视频的颜色模型转换和色域{?/span>
[链接] http://www.52im.net/thread-4467-1-1.html
[摘要] 本文以通俗易懂的文字，引导你理解视频是如何从采集开始，历经各种步骤Q最l通过颜色模型转换和不同的色域转换Q让你看到赏心悦目的视频l果的?/p>
👉52imC本周新文Q?a target="_blank" rel="noopener" style="color: #1d58d1; text-decoration-line: none;">跟着源码学IM(十二)Q基于Netty打造一N性能的IMx通讯E序》，Ƣ迎阅读Q?/p>
我是Jack JiangQ我已带盐！https://github.com/JackJiang2011/MobileIMSDK/
Z更好地分c阅?52im.net 总计1000多篇_文章Q我在每周三推送新的一期技术文集，本次是第 24 期?/p>
[- 1 -] 开源实旉视频技术WebRTC的现?/span>
[链接] http://www.52im.net/article-126-1.html
[摘要] 作ؓGoogle开源的技术，WebRTCq不是一个可以拿来就用ƈ且性能很好的品，而且正如众多的其它开源技术一PWebRTC的发展ƈ没有期待中的快?/p>
[- 2 -] q开源实旉视频技术WebRTC的优~点
[链接] http://www.52im.net/thread-225-1-1.html
[摘要] 作ؓGoogle开源的技术，WebRTCq不是一个可以拿来就用ƈ且性能很好的品，需要工E师们对其进行较多的改善。本文主要来谈一谈WebRTC的优~点?/p>
[- 3 -] 访谈WebRTC标准之父QWebRTC的过厅R现在和未来
[链接] http://www.52im.net/thread-227-1-1.html
[摘要] 首届QWebRTCQ网l实旉信大会期间QInfoQ ?WebRTC 之父 Daniel C. Burnett q行了专访，以下是专访实录。（注：Daniel 在访谈中的观点仅代表他本人及其在 W3C 所做的工作。）
[- 4 -] 良心分nQWebRTC 零基开发者教E（中文Q[附g下蝲]
[链接] http://www.52im.net/thread-265-1-1.html
[摘要] WebRTCQ名U源自网实旉信QWeb Real-Time CommunicationQ的~写Q是一个支持网|览器q行实时语音通话或视频聊天的技术，是谷?010q以6820万美元收购Global IP Solutions公司而获得的一Ҏ术?/p>
[- 5 -] WebRTC实时韌频技术的整体架构介绍
[链接] http://www.52im.net/thread-284-1-1.html
[摘要] 虽然WebRTC的目标是实现跨^台的Web端实旉视频通讯Q但因ؓ核心层代码的Native、高品质和内聚性，开发者很Ҏq行除Webq_外的UL和应用。很长一D|间内WebRTC是业界能免费得到的唯一高品质实旉视频通讯技术?/p>
[- 6 -] 新手入门Q到底什么是WebRTC服务器，以及它是如何联接通话的？
[链接] http://www.52im.net/thread-356-1-1.html
[摘要] 通过WebRTC的端到端通信通常被h们所误解。WebRTCq不是真正意味着你不需要服务器来协商和联接通话。它只意味着Q在多数情况中，你可以直接地在浏览器之间q行通信?/p>
[- 7 -] WebRTC实时韌频技术基Q基本架构和协议?/span>
[链接] http://www.52im.net/thread-442-1-1.html
[摘要] 本文主要介绍WebRTC的架构和协议栈?/p>
[- 8 -] 谈开发实时视频直播^台的技术要?/span>
[链接] http://www.52im.net/thread-475-1-1.html
[摘要] 现在大大小的公司，甚至个h开发者，都想开发自q直播|站或AppQ本文会帮你理清Q开发视频直播^収ͼ你需要注意哪些技术要炏V?/p>
[- 9 -] [观点] WebRTC应该选择H.264视频~码的四大理?/span>
[链接] http://www.52im.net/thread-488-1-1.html
[摘要] 对实旉视频开发者来_当开发一个基于WebRTC的品时Q我们应该选择什么样的视频编解码器？d的时候，{案可能?#8220;VP8”。几个月前，{案可能?#8220;看情?#8221;。现在答案是“除非必须用VP8Q否则就用H.264”?/p>
[- 10 -] Z开源WebRTC开发实旉视频靠谱吗？W?方SDK有哪些？
[链接] http://www.52im.net/thread-510-1-1.html
[摘要] 利用Google开源的WebRTC来开发自已的实时韌频系l，靠不靠谱q个问题一直被问到Q其实很难一两句话说清楚Q因为答案不是一个靠谱或不靠谱可以回{好的，既然被反复问刎ͼ今天ql地整理参考答案?/p>
[- 11 -] 开源实旉视频技术WebRTC中RTP/RTCP数据传输协议的应?/span>
[链接] http://www.52im.net/thread-589-1-1.html
[摘要] 本文在深入研IWebRTC源代码的基础上，以Video数据的发送和接收ZQ力求用z语a描述RTP/RTCP模块的实现细节，一步深入掌握WebRTC打下良好基础?/p>
[- 12 -] q实旉视频聊天中端到端加密QE2EEQ的工作原理
[链接] http://www.52im.net/thread-763-1-1.html
[摘要] 本文着重阐q端到端加密(E2EE)Q端到端加密是确保数据传输安全的可行Ҏ之一。读完这文章，你可以了解这U加密方式的基本原理.
[- 13 -] 实时通信RTC技术栈之：视频~解?/span>
[链接] http://www.52im.net/thread-1034-1-1.html
[摘要] 那么 RTC 技术栈I竟包含哪些技术，我们会提供一pd文章Q来解读 RTC 技术栈。本文是pd文章的第一：讲述视频~解码的一些基本知识?/p>
[- 14 -] 开源实旉视频技术WebRTC在Windows下的明编译教E?/span>
[链接] http://www.52im.net/thread-1125-1-1.html
[摘要] WebRTC是提供了一整套处理实时韌频的开源库。它包括了音视频处理Q采集，~解码，前处理，后处理，渲染Q，数据传输Q实时传输，控Q和业务逻辑控制。可以说 WebRTC 的出现大大减了做音视频开发的隑ֺQ所以熟l掌握好q个库对于做韌频相关的同学显的特别重要了?/p>
[- 15 -] |页端实旉视频技术WebRTCQ看h很美Q但ȝ产应用还有多坑要填Q?/span>
[链接] http://www.52im.net/thread-1282-1-1.html
[摘要] 直到2011q_WebRTC技术的出现Qƈ且由h做推qѝWebRTC带来的体验是因ؓ免安装才受到了关注?/p>
[- 16 -] 了不LWebRTCQ生态日完善，或将实时韌频技术白菜化
[链接] http://www.52im.net/thread-1631-1-1.html
[摘要] 有h?2017 q是 WebRTC 的{折之q_2018 q将?WebRTC 的爆发之q_qƈ非没有根据。就在去q_2017q_QWebRTC 1.0 标准草案出炉Q实际上WebRTC标准草案的早期版本早?011q就已经发布QWebRTCq一夜之间就出现的技术）Qƈ于今年正式发布。与此同Ӟ来多的浏览器和厂商都开始对它进行广泛的支持QWebRTC 卛_成ؓ互联|的基础设施了，或许门槛如此之高的实旉视频技术终有白菜化的那一天?/p>
[- 17 -] 腾讯技术分享：微信程序音视频与WebRTC互通的技术思\和实?/span>
[链接] http://www.52im.net/thread-1988-1-1.html
[摘要] 本文来自腾讯视频云终端技术ȝrexchangQ常青）技术分享，内容分别介绍了微信小E序视音视频和WebRTC的技术特征、差异等Qƈ针对两者的技术差异分享和ȝ了微信小E序视音视频和WebRTC互通的实现思\以及技术方案。希望能带给你启发?/p>
[- 18 -] 融云技术分享：ZWebRTC的实旉视频首昄旉优化实践
[链接] http://www.52im.net/thread-3169-1-1.html
[摘要] 本文主要通过对WebRTC接收端的韌频处理过E分析，来了解和优化视频首的显C时_q进行了ȝ和分享?/p>
[- 19 -] 零基入门Q基于开源WebRTCQ从0?实现实时韌频聊天功?/span>
[链接] http://www.52im.net/thread-3680-1-1.html
[摘要] 本文基于笔者公司开发的在线问诊产品中WebRTC技术的实践l验Q讲q的如何ZWebRTC从零开发一个实旉视频聊天功能。文章会从WebRTC的基本知识、技术原理开始，Z开源技术ؓ你演C如何搭Z个WebRTC实时韌频聊天功能?/p>
[- 20 -] 实时韌频入门学习：开源工EWebRTC的技术原理和使用析
[链接] http://www.52im.net/thread-3804-1-1.html
[摘要] WebRTCQ全U?Web Real-Time CommunicationQ，即网即旉信。是一个支持网|览器q行实时语音对话或视频对话的技术方案。从前端技术开发的视角来看Q是一l可调用的API标准?/p>
👉52imC本周新文Q?a target="_blank" rel="noopener" style="color: #1d58d1; text-decoration-line: none;">哔哩哔哩??自研客服IMpȝ的技术实践之?nbsp;http://www.52im.net/thread-4517-1-1.html》，Ƣ迎阅读Q?/p>
我是Jack JiangQ我已带盐！https://github.com/JackJiang2011/MobileIMSDK/
Z更好地分c阅?52im.net 总计1000多篇_文章Q我在每周三推送新的一期技术文集，本次是第23 期?/p>
[- 1 -] 理论联系实际Q一套典型的IM通信协议设计详解Q含安全层设计）
[链接] http://www.52im.net/thread-283-1-1.html
[摘要] 本文以理论联系实际的方式，详细讲解一套典型IM的通信协议设计的方斚w面?/p>
[- 2 -] 微信C代通信安全解决ҎQ基于TLS1.3的MMTLS详解
[链接] http://www.52im.net/thread-310-1-1.html
[摘要] 通信安全是互联网应用首要考虑的问题，有别于传lPC应用Q随着Ud互联|时代的到来Q移动端的通信安全性要同时权衡Q安全、性能、体验、数据流量等{方面，要实C个完整而实用的通信安全解决Ҏq易事。本文将详细介绍ZTLS 1.3的微信新一代通信安全协议mmtls?/p>
[- 3 -] 来自阉KOpenIMQ打造安全可靠即旉讯服务的技术实践分?/span>
[链接] http://www.52im.net/thread-215-1-1.html
[摘要] OpenIM是阿里巴巴推出的Q集成于阉K癑ַ目中的Ud端IM开放服务。阿里百川是阉K巴巴集团无线开攑^収ͼ为移动开发者（늛Ud创业者）提供快速搭建APP、加速APP商业化、提升用户体验的解决Ҏ?/p>
[- 4 -]q实旉视频聊天中端到端加密
[链接] http://www.52im.net/thread-763-1-1.html
[摘要] 本文着重阐q端到端加密(E2EE)Q端到端加密是确保数据传输安全的可行Ҏ之一。读完这文章，你可以了解这U加密方式的基本原理.
[- 5 -] Ud端安全通信的利?#8212;—端到端加密（E2EEQ技术详?/span>
[链接] http://www.52im.net/thread-764-1-1.html
[摘要] 端到端加密允许数据在从源点到l点的传输过E中始终以密文Ş式存在。采用端到端加密Q又U脱U加密或包加密）时消息在被传输时到达l点之前不进行解密，因ؓ消息在整个传输过E中均受C护，所以即使有节点被损坏也不会使消息泄霌Ӏ?/p>
[- 6 -] Web端即旉讯安全Q跨站点WebSocket劫持漏洞详解(含示例代?
[链接] http://www.52im.net/thread-793-1-1.html
[摘要] 本文深入浅Zؓ读者介l跨站点 WebSocket 漏洞的原理、检方法和修复ҎQ希望能帮助q大读者在实际工作中避免这个已知安全漏z?/p>
[- 7 -] 通俗易懂Q一掌握即旉讯的消息传输安全原?/span>
[链接] http://www.52im.net/thread-970-1-1.html
[摘要] 本文通过通俗易懂的文字，引导你一步步理解Z一个即旉讯应用需要加密技术，以及需要何U方式的加密技术等Q希望能为您的IM或消息推送服务的设计提供一些参考?/p>
[- 8 -] IM开发基知识补课(?Q正理解HTTP短连接中的Cookie、Session和Token
[链接] http://www.52im.net/thread-1525-1-1.html
[摘要] 本文讨论的用Http短连接的话题可能q不适用于微信这LIMQ因为微信的短连接ƈ非用Http标准协议实现Q而是Z自研的Mars|络层框架再造了一套短q接机制Q从而更适用于IMq种场景Q更低gq、更省流量、更好的q适应法{）
[- 9 -] 快速读懂量子通信、量子加密技?/span>
[链接] http://www.52im.net/thread-1604-1-1.html
[摘要] 量子通信技术是个很高端的话题，对于搞IM、推送、网l通信的程序员来说Q这到底是个什么鬼Q所以我们一h了解一下！
[- 10 -] x通讯安全（七）Q如果这h理解HTTPS原理Q一就够了
[链接] http://www.52im.net/thread-1890-1-1.html
[摘要] 本文尝试用通俗易懂的语aQ一步步q原HTTPS的设计过E，以便您能L理解Z么HTTPS最l会是这副模栗?/p>
[- 11 -] 一分钟理解 HTTPS 到底解决了什么问?/span>
[链接] http://www.52im.net/thread-2027-1-1.html
[摘要] 本文只做单的描述Q力求简单明了的阐明主要内容Q因为HTTPS 体系非常复杂Q这么短的文字是无法做到很详l和_և的分析。想要详l了解HTTPS的方斚w面，可以阅读此前x通讯|整理的《即旉讯安全（七）Q如果这h理解HTTPSQ一就够了》一文?/p>
[- 12 -] 一读懂HTTPSQ加密原理、安全逻辑、数字证书等
[链接] http://www.52im.net/thread-2446-1-1.html
[摘要] HTTPSQ全UͼHypertext Transfer Protocol SecureQ超文本传输安全协议Q，是以安全为目标的HTTP通道Q简单讲是HTTP的安全版。本文，来深入介绍下其原理?/p>
[- 13 -] ZNetty的IM聊天加密技术学习：一文理清常见的加密概念、术语等
[链接] http://www.52im.net/thread-4104-1-1.html
[摘要] 本文正好借此ZQ以Netty~写的IM聊天加密ZQؓ入门者理清什么是PKI体系、什么是SSL、什么是OpenSSL、以及各c证书和它们间的关系{，q在文末附上短的Netty代码实示例，希望能助你通俗易懂地快速理解这些知识和概念Q?/p>
[- 14 -] 手把手教你ؓZNetty的IM生成自签名SSL/TLS证书
[链接] http://www.52im.net/thread-4142-1-1.html
[摘要] 本文要分享的是如何用OpenSSL生成在基于Netty的IM中真正可用的SSL/TLS证书Q内容包括：证书的创建、创E中的注意点Q以及在Server端、Android端、iOS端、Java桌面端、H5端用证书的代码范例?/p>
[- 15 -] 微信技术分享：揭秘微信后台安全特征数据仓库的架构设?/span>
[链接] http://www.52im.net/thread-4374-1-1.html
[摘要] 本文介l微信的安全数据特征仓库的背景v源、技术演q、当前的架构设计和实践，以及数据质量保证pȝ的实现。希望给中大型IMpȝ的安全数据特征仓库的设计带来启发?/p>
👉52imC本周新文Q?a target="_blank" rel="noopener" style="color: #1d58d1; text-decoration-line: none;">微信团队分nQ详解iOS版微信视频号直播中因帧率异常D的功耗问?/a>》，Ƣ迎阅读Q?/p>
我是Jack JiangQ我已带盐！https://github.com/JackJiang2011/MobileIMSDK/
源代码：https://gitee.com/yifan88899/acttest
## 版本说明
- springboot 2.4.2
- activiti 7.1.0.M6
- mysql 8.0.28
## 插g安装
- Activiti BPMN visualizer
## Bpmn程图位|?br />- 程?/span>xml?/span>png需攑֜resources/processes?br />## Test
- Test Case 都可执行Q包括：
- 程查询
- 程部v
- 程启动
- 程拑֏、完成操?br />## Mysql
- 需要启?/span>Mysql8
- 数据库名Activiti7
- activiti会版
]]>
本文由小U书基础架构存储l空z和刘备分nQ原?#8220;红书如何应对万亿C交|络关系挑战Q图存储pȝ REDtao 来了Q?#8221;Q本文有修订和改动?/p>
1、引a
红书是一个社区属性ؓȝ产品Q它늛了各个领域的生活CQƈ存储量的社交网l关pR?/p>
Z解决C交场景下超大规模数据的更新与关联读取问题，q减数据库压力和成本，我们自研了面向超大规模社交网l的囑֭储系l?REDtaoQ大大提高了pȝE_性。该pȝ借鉴?Facebook 的图存储pȝ设计Q将~存和底层数据库装hQƈ对外提供l一的图查询 APIQ实C讉K收敛Q同时在~存中实C高效的边聚合?/p>
本文ؓ你分享小U书面向大规模C交|络的图存储pȝREDtao的架构设计与技术实践过E，希望能带l你启发?/strong>
- Ud端IM开发入门文章：?a rel="noopener" target="_blank" style="color: #1d58d1; text-decoration-line: none;">新手入门一就够：从零开发移动端IM?/p>
- 开源IM框架源码Q?a rel="noopener" target="_blank" style="color: #1d58d1; text-decoration-line: none;">https://github.com/JackJiang2011/MobileIMSDKQ?a rel="noopener" target="_blank" style="color: #1d58d1; text-decoration-line: none;">备用地址ҎQ?/p>
Q本文已同步发布于：http://www.52im.net/thread-4495-1-1.htmlQ?/p>
2、关于作?/h1>
I洞Q?/strong>红书基架构存储l，负责囑֭储系l?REDtao 和分布式~存的研发?/p> 刘备Q?/strong>红书基架构存储l负责hQ负责REDkv / REDtao / REDtable / REDgraph 的整体架构和技术演q?/p> 基础架构存储l是l小U书的业务部门提供稳定可靠的存储和数据库服务Q满业务对存储产品的功能、性能、成本和E_性要求。目前负责自研分布式 KV、分布式~存、图存储pȝ、图数据库和表格存储?/p> 已上U的存储产品包括Q?/strong> 红书是以年MhZ的生z记录、分享^収ͼ用户可以通过短视频、图文等形式记录生活ҎQ分享生zL式?/p> 在小U书的社交领域里Q我们有用户、笔记、商品等实体Q这些实体之间有各种各样的关pR?/p> 例如Q?/strong>用户与笔C间可能存?#8220;拥有”Q发布）?#8220;点赞”?#8220;收藏”{三U关p，同时q存在对应的反向关系“被点?#8221;Q?#8220;被收?#8221;{?/p> 红书的C交图谱数据已经辑ֈ了万亿条边的规模Q且增长速度非常快。当用户登陆红书时Q每个用户都会看到关注的好友、粉丝、点赞、收藏以及其他ؓ光w定做的内容?/p> q些信息高度个性化Q需要实时从q些量C交关系数据中读取用L关信息。这是一个读Z的过E，d压力非常大?/p> q去Q我们将q些C交图谱数据都存储在q维成熟?MySQL 数据库中?/p> 然而，即我们只有百万h每秒的规模，MySQL ?CPU 使用率仍然到达了 55% 。随着用户?DAU 爆发式的增长Q需要不断扩?MySQL 数据库，q带来了巨大的成本和E_性压力?/p> Z解决q些问题且考虑到没有合适的开源方案，2021 q初我们开启了?0 ?1 自研 REDtao 的历E?/strong> 我们充分调研了业内其他厂商的实现Q发现有着强社交属性的公司基本上都有一个自研的囑֭储系l（如下图所C）?/p> 比如Q?/strong> 考虑到当时我们的C交图谱数据已经存放?MySQL 数据库上且规模巨大，而社交图谱数据服务是非常重要的服务，对稳定性的要求非常高。回?Facebook 当年遇到的问题和我们cMQ数据存储在 Memcache ?MySQL 中。因此，参?Facebook ?Tao 囑֭储系l更贴合我们的实际情况和已有的技术架构，风险更小?/strong> C交图谱的访问主要是边的关系查询?/p> 我们的图模型关p表CZؓ一?nbsp;<key, value> 对，其中 key ?( FromId, AssocType, ToId ) 的三元组Qvalue 是属性的 JSON 格式?/p> 比如“用户 A ”x“用户 B ”Q映到 REDtao 的数据存储结构ؓQ?/strong> 1<FromId:用户A的ID, AssocTypeQ关注， ToIdQ用户B的ID> -> Value Q属性的json字段Q?/p> 我们对业务方的需求进行分析，装?25 个图语义?API l业务方使用Q满了其增删改查的需求，q收敛业务方的用方式?/p> 相比?Facebook ?TaoQ我们还补充了社交图谱所需要的图语义，为反作弊场景提供了额外的qo参数?/p> 同时Q在~存层面Q我们支持对不同的字D在~存中配|局部二U烦引?/p> 下面l一些典型的使用场景?/p> 1Q场景一Q?/em>获取x?A 的所有正常用Pq且剔除作弊用户Q： 1getAssocs(“被关注类?#8221;, 用户A的ID, 分页偏移? 最大返回? 只返回正常用P是否按照旉从新到旧) 2Q场景二Q?/em>获取 A 的粉丝个敎ͼq且剔除作弊用户Q： 1getAssocCount(“被关注类?#8221;, 用户A的ID, 只返回正常用? REDtao 的架构设计考虑了下面这几个关键的要素： 整体架构分ؓ三层Q?/strong> 业务斚w过 REDtao SDK 接入服务?/p> 如下图： 在这个架构中Q?/strong>?Facebook Tao 不一L是，我们的缓存层是一个独立的分布式集，和下面的持久层是解耦的。缓存层和下面的持久层可以独立的扩容~容Q缓存分片和 MySQL 分片不需要一一对应Q这样带来了更好的灵zL，MySQL 集群也变成了一个可以插拔替换的持久存储?/p> 1Q读程Q?/em>客户端将读请求发送给 routerQrouter 接收?RPC h后，Ҏ边类型选择对应?REDtao 集群Q根据三元组 ( FromId, AssocType, ToId ) 通过一致?Hash 计算出分片所在的 Follower 节点Q将h转发到该节点上。Follower 节点接收到该hQ首先查询本地的囄存，如果命中则直接返回结果。如果没有命中，则将h转发l?Leader 节点。同LQLeader 节点如果命中则返回，如果不命中则查询底层 MySQL 数据库?/p> 2Q写程Q?/em>客户端将写请求发送给 routerQ和LE一P会{发到对应?Follower 节点上。Follower 节点会{发写hl?Leader 节点QLeader 节点转发l?MySQLQ当 MySQL q回写入成功后，Leader 会清除本地图~存对应?KeyQƈ同步l其他所?Follower 清除掉该 KeyQ保证数据的最l一致性?/p> REDtao 分ؓ独立的两层：~存层和持久层。每一层都保证高可用性?/p> 1Q自研的分布式缓存： 我们自研了实现图语义的分布式 cache 集群Q支持故障自动检和恢复、水qx~容?/p> 它是一个双?cacheQ每个分片都有一?Leader 和若q个 Follower。所有的h都先发给外层?FollowerQ再?Follower 转发l?Leader。这L好处是读压力大的时候只需要水qx?FollowerQ单?Leader 写入的方式也降低了复杂度Q更Ҏ实现数据的一致性?/p> 如果一个副本故障，pȝ会在U别内q行切换。当持久层发生故障时Q分布式~存层仍然可以对外提供读取服务?/p> 2Q高可用的MySQL集群Q?/em> MySQL 集群通过自研的中间g实现了分库分表方案，q支?MySQL 的水qx宏V每?MySQL 数据库有若干从库Qƈ且与公司内部其他?MySQL q维Ҏ一_保证高可用性?/p> 3Q限保护功能： 为防止缓存击I导?MySQL H发大量hQ从而导?MySQL 宕机Q我们通过限制每个主节Ҏ?MySQL q发h数来实现限流保护 MySQL。达到最大ƈ发请求限制之后的h会被挂v{待Q直到已有请求被处理q回Q或者达到等待超时请求被拒绝不会被l请求到 MySQL 。限阈值在U可调，Ҏ MySQL 集群规模调整对应限制?/p> 为防止爬虫或者作弊用户频J刷同一条数据，我们利用 REDtaoQueue 序执行对写入或者点查同一条边的请求，队列长度会被限制Q控制同一旉大量相同的请求执行。相比于单个全局的队列控制所有请求的方式Q基于每个请求的队列可以很好地限制单个同一hQ而不影响其他正常h?/p> 数据l构的设计是 REDtao 高性能的重要保证?/p> 我们采用了三层嵌?HashTable 的设? 通过Ҏ某个L from_id 从第一U?HashTable 中查扑ֈ REDtaoGraphQ记录了所?type 下对应的所有的信息?/p> 接着Q在W二U?HashTable 中，Ҏ某个 type_id 查找?AssocType 对应某个 type 下边所有出边的计数、烦引以及其他元数据?/p> 最l在最后一U?HashTable Q通过 AssocType 的某?to_id 查找到最l边信息?/p> 我们记录了创建时间、更新时间、版本、数据以?REDtaoQueueQtime_index 则对应根据创建时间排序列表?/p> 最后一U?HashTable 以及索引限制存储最新的 1000 个边信息Q以限制点占据过多内存，同时集中提高最新热数据的查询命中率以及效率。REDtaoQueue 用于排队当前某个关系的读写，只记录了当前最后一个请求的元数据?/p> 每次查询或写入时Q首先查?REDtaoAssocQ?/strong> 通过q种多层 hash+ 跌的设计，我们能高效地l织炏V边、烦引、时间序链表之间的关pR内存的甌、释攑֜同一个线E上完成?/p> 在线上环境中Q我们的pȝ可以在一?16 核的云厂商虚拟机上跑?150w 查询h/sQ同?CPU 利用率仅?22.5% 。下ҎU上集群的一个监控图Q单机的 QPS 到达 3w Q每?RPC h聚合?50 个查询?/p> 1Q丰富的图语?API Q?/em> 我们?REDtao 中封装了 25 个图语义?API l业务方使用Q满了业务方的增删Ҏ的需求。业务方无需自行~写 SQL 语句卛_实现相应操作Q用方式更加简单和收敛?/p> 2Q统一的访?URL Q?/em> ׃C后端数据太大Q我们按照不同的服务和优先拆分成了几个 REDtao 集群?/p> Z让业务方不感知后端的集群拆分逻辑Q我们实Cl一的接入层?/p> 不同的业务方只需使用同一个服?URL Q通过 SDK 请求发送到接入层。接入层会接收到不同业务方的图语义的hQƈҎ边的cd路由C同的 REDtao 集群。它通过订阅配置中心Q能够实时感知到边的路由关系Q从而实现统一的访?URLQ方便业务方使用?/p> 作ؓC交图谱数据Q数据的一致性至关重要。我们需要严g证数据的最l一致性以及一定场景下的强一致性。ؓ此，我们采取了以下措施： 1Q缓存更新冲H的解决Q?/em> REDtao 为每个写入请求生成一个全局递增的唯一版本受在使用 MySQL 数据更新本地~存Ӟ需要比较版本号Q如果版本号比缓存的数据版本低，则会拒绝此更新请求，以避免冲H?/p> 2Q写后读的一致性： Proxy 会将同一?fromId 的点或边h路由到同一个读 cache 节点上，以保证读取数据一致性?/p> 3Q主节点异常场景Q?/em> Leader 节点收到更新h后，会将更新h变ؓ invalidate cache h异步的发送给其他 followerQ以保证 follower 上的数据最l一致。在异常情况下，如果 Leader 发送的队列已满D invalidate cache h丢失Q那么会其他的 follower cache 全部清除掉?/p> 如果 Leader 故障Q新选D?Leader 也会通知其他 follower ?cache 清除?/p> 此外QLeader 会对讉K MySQL 的请求进行限，从而保证即使个别分片的cache被清除掉也不会将 MySQL 打崩?/p> 4Q少量强一致的hQ?/em> ׃ MySQL 的从库也提供L务，对于量要求Z致的读请求，客户端可以将h染上Ҏ标志QREDtao 会透传该标志，数据?Proxy 层会Ҏ该标志将读请求{发到 MySQL d上，从而保证数据的Z致?/p> 跨云多活是公司的重要战略Q也?REDtao 支持的一个重要特性?/p> REDtao 的跨云多zL构整体如下： q里不同?Facebook Tao 的跨云多zd玎ͼFacebook Tao 的跨云多zd现如下图所C?/p> Facebook 的方案依赖于底层?MySQL 的主从复刉通过 DTS Replication 来做。?MySQL 原生的主从复制是自n功能QDTS 服务q不包含 MySQL 的主从复制。该Ҏ需要对 MySQL ?DTS 做一定的攚w。前面说刎ͼ我们的缓存和持久层是解藕的，在架构上不一栗?/p> 因此QREDtao 的跨云多zL构是我们l合自n场景下的设计Q它在不改动现有 MySQL 功能的前提下实现了跨云多zd能?/p> 1Q?/em>持久层我们通过 MySQL 原生的主?binlog 同步数据复制到其他云的从库上。其他云上的写请求和量要求Z致读被转发C库上。正常的读请求将d本区?MySQL 数据库，满读请求对时g的要求?/p> 2Q?/em>~存层的数据一致性是通过 MySQL DTS 订阅服务实现的，?binlog 转换?invalidate cache hQ以清理掉本?REDtao cache 层的 stale 数据。由于读h会随取本区的M一?MySQL 数据库，因此 DTS 订阅使用了一个gq订阅的功能Q保证从 binlog 同步最慢的节点中读取日志，避免 DTS ?invalidate cache h和本?read cache miss 的请求发生冲H从而导致数据不一致?/p> REDtao 的云原生Ҏ重点体现在Ҏ~、支持多 AZ ?Region 数据分布、品可以实现在不同的云厂商间迁Uȝ几个斚w。REDtao 在设计之初就考虑到支持弹性扩~容、故障自动检及恢复?/p> 随着 Kubernetes 云原生技术越来越成熟Q我们也在思考如何利?k8s 的能力将部v和虚拟机解绑Q进一步云原生化，方便在不同的云厂商之间部|和q移?/p> REDtao 实现了一个运行在 Kubernetes 集群上的 OperatorQ以实现更快的部|Ӏ扩容和坏机替换?/p> Z?k8s 能感知集分片的分配q且控制同一分片下的 Pods 调度在不同宿L上，集群分组分片分配?k8s Operator 渲染q控制创?DuplicateSet Q小U书自研 k8s 资源对象Q?/p> REDtao 则会创徏Mq根?Operator 渲染出来的分片信息创建集，单个 Pod 故障重启会重新加入集，无需重新创徏整个集群。集升U时QOperator 通过感知M分配控制先从后主的顺序，按照分片分配的顺序滚动升U以减少升期间U上影响?/p> 但凡变革Q皆属不易。实现全新的 REDtao 只是完成了相对容易的那部分工作?/p> 红书的C交图谱数据服务已经?MySQL 上运行多q_有很多不同的业务跑在上面QQ何小的问题都会媄响到红书的在线用户。因此，如何保证不停服的情况下让现有业务无感知地q移?REDtao 上成Z个非常大的挑战?/p> 我们的迁Ud作关键有两点Q?/strong> 1Q?/em>老的?MySQL 集群按优先拆分成了四个 REDtao 集群。这P我们可以先将优先U最低的服务q移C?REDtao 集群Q充分灰度后再迁U高优先U的集群Q?/p> 2Q?/em>专门开发了一?Tao Proxy SDKQ支持对原来?MySQL 集群?REDtao 集群q行双写双读Q数据校验比寏V?/p> q移Ӟ我们首先低优先U的数据?MySQL 通过 DTS 服务q移C一?REDtao 集群Qƈ升好业务方?SDK 。DTS 服务一直对增量数据q行同步。业务方 SDK 会订阅配|中心的配置变更Q我们修攚w|让 Tao Proxy SDK 同时d MySQL 集群?REDtao 集群Qƈ关闭 DTS 服务。此时会使用 MySQL 集群的结果返回给用户?/p> 在停?DTS 服务Ӟ有可能会有新?MySQL 数据通过 DTS 同步q来Q造成?REDtao 集群新写的数据被同步q来的老数据覆盖。因此，在关?DTS 服务后，我们会通过工具d开双写之后到关?DTS 服务q个旉D늚 binlog Ҏ据进行校验和修复?/p> 修复完成之后Q?/strong>Tao Proxy SDK 的双M展示两边不一致的数据量，q过滤掉因ؓ双写时g不一致导致数据不一致的h。灰度一D|间后观察?diff 的数目基本ؓ 0Q将 Tao Proxy SDK 的配|改为只d新的 REDtao 集群?/p> 最l：我们?22 q初完成红书所有核心社交图׃亿边U别数据的迁Ud正确性校验，q做C整个q移服务无感知，q移q程没有发生一h障?/p> 我们的社交图谱数据访问中Q?0% 以上的请求都是读hQƈ且社交图q数据有非常强的时间局部性（xq更新的数据最Ҏ被访问）。REDtao 上线后，获得 90% 以上?cache 命中率， 对MySQL ?QPS 降低?70%+ Q大大降低了 MySQL ?CPU 使用率。在~容 MySQL 的副本数目后Q整体成本降低了21.3%?#8205; 业务的访问方式都全部收敛?REDtao 提供?API 接口上，在迁U过E中Q我们还ȝ了一些老的不合理访?MySQL 数据库的方式Q以及自定义某些字段赋予Ҏ含义的不合理做法Q通过 REDtao 规范了数据访问?/p> Ҏ 2022 q初?2023 q初Q随着 DAU 的增长，C交图谱的请求增长了 250% 以上Q如果是之前 MySQL 的老架构，扩容资源基本上和h增长速度成正比，臛_需要扩?1 倍的资源成本Q数万核Q?/p> 而得益于 REDtao pȝ的存在，因其 90% 的缓存命中率Q实际上整体成本只增加了 14.7%Q数千核Q就能扛?2.5 倍的h增长。在成本和稳定性上有了较大的提升?/p> 在较短的旉Q我们自研了囑֭储系l?REDtao Q解决了C交图谱关系数据快速增长的问题?/p> REDtao 借鉴?FaceBook Tao 的论文，q对整体架构、跨云多zd了较多的改进Q全新实C一个高性能的分布式囄存，更加贴合我们自n的业务特点和提供了更好的Ҏ。同Ӟ利用 k8s 能力q一步实C云原生化?/p> 随着 DAU 的持l增长，万亿的数据规模也在l增长，我们也面临着更多的技术挑战?/p> 目前公司内部?OLTP 囑֜景主要分Z块： 1Q?/em>C交图谱数据服务Q?/span>通过自研囑֭储系l?REDtao 满了社交场景超大规模数据的更新与关联读取问题。目前已l存储了万亿规模的关p； 2Q?/em>风控场景Q?/span>通过自研图数据库 REDgraphQ满_跳的实时在线查询。目前存储了千亿点和边的关系Q满?2 跳以?2 跳以上的查询Q?/p> 3Q?/em>C交推荐Q?/span>q块主要是两跳的查询。每天通过 Hive 扚w地导入全量的数据Q通过 DTS 服务q实时的写入更新数据。因为是在线场景Q对时g的要求非帔RQ当前的 REDgraph q无法满么高的要求，因此业务方主要是?REDkv 来存储?/p> 针对以上场景Q?/strong>Z快速满业务需求，我们使用了三套不同的自研存储pȝQREDtao 、REDgraph ?REDkv ?/p> 昄相对?3 套存储系l，用一个统一的架构和pȝ去解册几个囄关的场景是更加合适的?/p> 未来Q?/strong>我们会将 REDgraph ?REDtao 融合成一个统一的数据库产品Q打造业内顶的图技术，对公司内部更多的场景q行赋能?/p> [1] 以微博类应用场景ZQȝ量C交pȝ的架构设计步?/a> [2] 腾讯技术分享：C交|络囄的带宽压~技术演q之?/a> [3] ZC交|络的Yelp是如何实现v量用户图片的无损压羃的？ [4] C交软gU包技术解?一)Q全面解密QQU包技术方?#8212;—架构、技术实现等 [5] C交软gU包技术解??Q微信红包系l的存储层架构演q实?/a> [6] C交软gU包技术解??Q谈谈手QU包的功能逻辑、容灾、运l、架构等 [7] 渐行渐远的h人网Q十q亲历者的互联|社交品复盘和反?/a> [8] 中国互联|社交二十年Q全民见证的互联|创业演?/a> [10] 盘点Ud互联|时代的C交产品q化Ԍ下篇Q：大浪淘沙3、技术背?/h1>
4、方案调研和API设计
4.1Ҏ调研
4.2API设计
5、整体架构设?/h1>
6、高可用设计
7、高性能设计
8、易用性设?/h1>
9、数据一致性设?/h1>
10?跨云多活设计
11、云原生实现
12、老服务的qx升实践
13、新囑֭储系l带来的l果和收?/h1>
14、未来展?/h1>
15、相兌?/h1>
Q本文已同步发布于：http://www.52im.net/thread-4495-1-1.htmlQ?/p>