关于im:如何快速构建可靠的分布式IM聊天系统

起源:如何疾速构建牢靠的分布式IM聊天零碎 tlnetim 聊天我的项目是一个分布式 im demo,基于 tlnet http框架和 tldb数据库。tldb是一个高性能的分布式数据库,基于tldb能够疾速构建分布式系统。 tlnetim 的开源程序: https://github.com/donnie4w/tlnetimhttps://gitee.com/donnie4w/tlnetimtlnetim次要的性能:多聊天室多人聊天零碎,程度扩大多服务器部署构建分布式im.tlnet.top与im2.tlnet.top 是分布式系统的两个不同的服务 用户能够连贯任意一个服务器相互通信除去局部存储数据的实现,im的逻辑代码理论只有几十行,基于tldb mq代码实现分布式的代码也只有几十行。 room, ok := wsmap.Get(ws)if !ok { if wa.ATYPE == LOGIN { if iu, ok := getUserInfo(wa.MSG); ok { room = strings.TrimSpace(wa.ROOM) store(ws, iu, room) //记录登录日志 orm.Insert(&ImLog{UserId: iu.Id, Room: room, Time: TimeNow()}) ws.Send(wsack{ATYPE: wa.ATYPE, USERNAME: iu.Name, ICON: iu.Icon, TIME: TimeNow(), ROOM: room}.toJson()) immq.PubId(room, iu.Id) //返回好友列表 if *UseRobot { ws.Send(wsack{ATYPE: FRIEND, USERNAME: robot.Name, ICON: robot.Icon, LABEL: robot.Label}.toJson()) } broadcastToSelf(&wsack{ATYPE: FRIEND}, ws, room) //告诉好友 broadcast(&wsack{ATYPE: FRIEND, USERNAME: iu.Name, TIME: TimeNow(), ICON: iu.Icon}, ws, room, true, true) //返回聊天室 最新N条数据 if id, _ := orm.SelectIdByIdx[ImMessage]("Room", room); id > 0 { startid := id - 20 if startid < 0 { startid = 0 } if ims, _ := orm.SelectByIdxLimit[ImMessage](startid, 21, "Room", room); ims != nil { for _, im := range ims { var u *ImUser if im.UserId > 1<<60 { u = robot } else { u, _ = orm.SelectById[ImUser](im.UserId) } if u != nil { ws.Send(wsack{ATYPE: MSG, USERNAME: u.Name, ICON: u.Icon, MSG: im.Content, TIME: im.Time}.toJson()) } } } } } else { ws.Send(wsack{ATYPE: NOPASS}.toJson()) } }} else if wa.ATYPE == MSG { iu, _ := getIu(room, ws) t := TimeNow() //保留聊天信息 if _, err := orm.Insert(&ImMessage{UserId: iu.Id, Content: wa.MSG, Time: t, Room: room}); err == nil { //发送聊天数据 broadcast(&wsack{ATYPE: MSG, USERNAME: iu.Name, MSG: wa.MSG, TIME: t, ICON: iu.Icon}, nil, room, true, false) }}tlnet将服务器的websocket封装为 三个阶段: ...

September 5, 2023 · 3 min · jiezi

关于im:环信入选中小企业数字化转型-IM-报告领导者象限

近日,市场调研咨询机构向量智库公布了《中小企业数字化转型 IM 测评报告》(以下简称《报告》),解析国内中小企业 IM 市场规模及浸透状况,以及 IM 品牌在中国外乡格局散布。环信作为国内 IM 即时通讯畛域的领导者,凭借在 IM 畛域的技术创新和服务能力胜利入选领导者象限,其中技术评分排名行业第一。这一问题的获得,充分体现了环信在中小企业数字化转型畛域的领先地位和卓越技术实力。同时也是对环信多年来深耕企业级通信畛域,一直摸索和翻新的必定和认可。环信入选领导者象限6 月 14 日,财政部、工信部公布《对于发展中小企业数字化转型城市试点工作的告诉》(以下简称《告诉》)。此次公布的《告诉》指出,聚焦中小企业数字化转型中的痛点难点,围绕提质、增效、降本、减存、绿色、平安的指标,晋升数字化转型服务供应能力,升高转型老本,确保中小企业数字化转型取得实效。IM(即时通讯)在助力中小企业数字化转型中正在表演越来越重要的角色。依据《报告》数据显示,2018 年-2023 年中国中小企业 IM 市场均匀增速超过 25% ,国内市场业务在线化的趋势越来越明确,IM 与中国中小企业日常经营的联合也越发深刻。IM(即时通讯)作为一种企业级通信工具,可能为企业提供高效、实时的沟通形式,帮忙企业突破传统的沟通壁垒,进步沟通效率和合作能力。目前,IM 已成为少数外乡中小企业的数字化“启蒙者”,随同着企业一起成长。互联网外围价值是连贯,底层能力是通信,IM PaaS 通信能力可让开发者以 SDK/API 模式调用并集成 IM 能力到利用中,包含音讯传输、群组治理、会话治理等通信能力,其中音讯类型包含文字、表情、图片、语音、视频、文件、告诉等。IM PaaS 作为互联网基础设施服务之一曾经成为中小企业数字化转型的基石。环信基于 IM PaaS 打造的智能挪动办公平台“环信通”反对全端(Linux、Windows、macOS、Android 和 iOS)笼罩,提供即时通讯、音视频会议、企业通讯录、协同办公、信息安全、工作台等多种性能,反对开箱即用,为中小企业数字化转型插上了一对翅膀。环信技术评分行业第一环信 IM PaaS 平台六大技术个性:1、 高可用性 环信 IM 技术通过以下形式实现高可用性:负载平衡:通过负载平衡技术,将用户的申请平衡地调配到多个服务器上,从而分担单个服务器的压力,保证系统的稳定性和效率。数据冗余:环信 IM 技术采纳分布式架构,对数据进行冗余备份,即便某个服务器呈现故障,也可能实现数据的主动转移和复原,保证数据的安全性和可靠性。主动扩容:随着用户量的增长,平台能够依据需要主动扩容,通过增加更多的服务器来分担负载并放弃零碎的高可用性。监控和预警:环信 IM 的运维零碎实时监控零碎各项指标,如服务器的运行状态、网络提早、消息传递速度等,一旦出现异常状况,零碎会主动收回预警告诉相干人员及时进行解决。 2、高可靠性 环信数据中心同城三核心部署,SLA 99.95%。 优异的弱网反抗能力,70% 丢包状况下音讯达到率 100%。音讯投递的过程依附客户端 ACK 的机制,业务上明确音讯曾经送达才会从服务端删除,从而保障音讯的可靠性投递。 3、高并发 在 IM 零碎中,高并发是一项必备的性能,因为用户发送和接管音讯操作频繁,须要在短时间内疾速响应,环信采纳分布式架构、负载平衡、异步解决等技术来实现高并发个性。环信反对同时在线人数无下限,聊天室亿级音讯散发,能够反对万人群组,聊天室人数可依据须要任意扩大。 4、安全性 为了确保通信过程的安全性,咱们采纳了一系列的措施,包含数据传输加密、用户认证、数据备份与复原等。数据传输加密是指咱们应用高强度的 SSL/TLS 协定对通信过程中的数据进行加密爱护,从而防止网络攻击者通过窃听、篡改等伎俩对敏感数据的获取。 5、易扩大易扩展性 是环信 IM 的一个外围特点,提供高度可扩大的架构和灵便的扩大机制,以满足不同场景和需要的利用。在架构层面,环信 IM 采纳分布式架构,通过程度扩大的形式实现性能的晋升。在利用层面,环信 IM 提供了灵便的 API 接口和丰盛的音讯类型来满足开发者自在扩大或集成本人的业务逻辑,满足各种不同场景的需要。 ...

September 1, 2023 · 1 min · jiezi

关于im:认识一下我们是应用社交幕后大佬-IM-家族

明天,就让咱们追随小 M 一起来认识一下: 艾瑞征询近期公布的《2023 年寰球互联网通信云行业钻研报告》(本公众号后盾回复【报告】获取完整版)显示,2021 年寰球互联网通信云市场规模达到 53 亿元。关注【融云寰球互联网通信云】理解更多深藏功与名的融云 IM 家族吧!如图片不清晰请点击 其中,中国占据了寰球互联网通信云服务的次要市场份额,头部厂商建设了当先劣势,互联网通信云市场集中度高。 在 IM PaaS 畛域,月独立设施数排名前 1000 的 App 中,融云笼罩的 App 日均设施数共计超过 8500 万台,居于业余互联网通信云厂商之首。 这意味着,融云曾经间断第 8 年以超过一半的市场份额占据统治位置

March 15, 2023 · 1 min · jiezi

关于im:你的聊天室该升级啦融云平滑迁移方案助你无感换乘

作为直播、语聊房等社交泛娱乐产品的必备组件,聊天室产品随着线上娱乐利用的暴发而取得了宽泛的利用,并在实践中一直拓展能力,成为主持语聊房和直播间秩序的“最高管理者”。关注【融云寰球互联网通信云】理解更多 在聊天室这个服务的比拼上,融云是性能实现、零碎性能、灵便便捷等方面的相对“能力者”,也因而取得了奇乐直播、N世界,DiDO、OHLA、Hektar、小象直播等国内外出名社交泛娱乐平台的青眼。N 世界-ISC 大会直播 其中,多个平台在融云的稳固服务下取得了高速增长和继续倒退,亦不乏更换服务商进入融云服务的“新群友”。 为不便开发者降级聊天室服务,更好反对业务发展,融云推出聊天室平滑迁徙解决方案,助力开发者无感迁徙、顺滑降级。 目前,融云已配合多款利用实现了平滑迁徙,造成了欠缺的迁徙工具和服务流程,开发者可在配合大量工作的状况下实现迁徙降级。 融云聊天室产品外围能力独家能力作为 IM 即时通讯领创品牌,通过多年技术积淀和宽泛场景实际,融云 IM 在以下开发者关怀的指标上体现均属行业当先。 低提早、高并发、稳定性技术支持服务开发文档可读性开发者后盾自助性反对场景、平台丰富性性能灵活性其中,在聊天室产品上,针对用户无下限的音讯海量并发状况,独家提供音讯分级策略,保障重要信息稳当下发。 同时,提供保活聊天室、整体禁言白名单等独家性能,以更齐全的性能和更弱小的灵活性满足开发者的场景需要。 音讯分级策略在聊天室音讯量微小的状况下,融云引入音讯分级机制,确保触发音讯摈弃策略时,用户端总能收到最重要的音讯。 同时,为保障聊天室中的重要音讯不被抛弃,融云提供聊天室用户白名单、聊天室音讯白名单等服务,爱护白名单中的音讯/用户所发消息,在聊天室音讯量大的状况下也不被抛弃。 保活聊天室通常,聊天室一小时无人谈话,同时没有人退出时,聊天室将主动销毁以防止资源节约。 针对须要长期保活聊天室的业务场景,融云提供聊天室保活性能,能够确保聊天室不被主动销毁,而是只能通过调用 API 接口销毁。 整体禁言白名单退出聊天室的禁言白名单后,在聊天室已被设置为整体禁言时,该成员仍可通过客户端 SDK 向该聊天室发送音讯,以满足相干业务经营需要。 灵便响应业务需要融云聊天室属性还具备丰盛个性以灵便反对各类实用业务需要反对强制设置单个属性、批量设置属性、房间信息预览,属性可随用户在线状态主动删除或继续保留,属性信息可实时同步客户的应用服务器以反对业务剖析数据、辅助经营。 其余外围能力☑ 丰盛的音讯类型和进阶性能:文字、语音、图片等丰盛内置音讯类型和可实现点赞、礼物等性能的自定义音讯类型;内容平安治理,包含敏感词设置、聊天内容反垃圾处理等;聊天室音讯治理性能,包含音讯散发管制等。 ☑ 便捷粗疏的聊天室治理性能:聊天室用户治理,包含创立、退出、销毁、禁言、查问、封禁(踢人)等;聊天室用户白名单性能,白名单用户处于被爱护状态不会被主动踢出,且发送音讯优先级别最高;聊天室实时统计及音讯路由等性能。 ☑ 人数无下限、海量大并发:满足聊天室用户高并发、快进出的特点,通过高可用架构、迷信的有限用户治理和音讯散发策略等确保聊天室的海量并发响应速度和散发速度,并提供平滑扩缩容计划以应答人数激增等业务个性。 ☑ 丰盛、实时、必达的聊天室属性:适配业务场景的麦位信息、角色身份、PK 状态、房间信息等多样化属性内容,并提供高阶个性以灵便反对各类实用业务需要;稳固牢靠的架构设计确保属性同步不丢不乱;分层存储保障属性变动实时同步。 融云聊天室平滑迁徙计划平滑迁徙计划需综合思考业务运行延续性、历史数据完整性、用户体验一致性、迁徙过程便捷性等关键点。 融云通过大量测试和实际验证,造成了一套蕴含计划征询、计划评估、施行服务、优化验证等关键环节在内的一体化迁徙解决方案,助力开发者轻松实现切换。 ☑ 业务运行延续性:提供新老 App 兼容和强制降级 App 两种迁徙形式,迁徙过程中不影响用户应用,保障业务连续性。 ☑ 历史数据完整性:提供历史音讯、本地音讯、离线音讯适配迁徙工具,保障数据安全和残缺。 ☑ 应用体验一致性:聊天室功能齐全,接口凋谢灵便、兼容性强,且相干性能的实现逻辑更加迷信,对开发者及 App 用户来说均可提供更顺滑的应用体验。 ☑ 迁徙过程便捷性:在融云多年技术积攒和高效服务根底上,积淀出欠缺的迁徙适配管理制度、流程、办法,迁徙周期短、过程简略、研发成本低,且有经验丰富的迁徙服务团队,及时解决迁徙疑难问题。

March 1, 2023 · 1 min · jiezi

关于im:第一篇用Uniapp仿微信的语音电话视频聊天IM聊天APP开发支持各类消息收发音视频通话等

前言基于uni-app技术开发的仿微信我的项目,实现了文本音讯、图文音讯、表情(gif动画),图片预览,图片编辑,视频预览,视频编辑,仿微信的图片抉择、编辑、长按菜单等性能一、我的项目意义作为一个企业或者集体,领有一款属于本人的IM即时聊天APP,能够在各个我的项目中不便的应用,我的项目十分稳固,平安,不须要破费大量的工夫精力去做开发或者要很高的费用开发聊天我的项目。二、应用到的技术本我的项目的目标是要用Uniapp开发一套能够媲美原生成果的仿微信IM,能够反对WEB IM,android,苹果版本,程序代码开源1.音讯收发2.音视频通话3.自定义拍照4.建群性能5.朋友圈性能6.加好友性能7.视频通话等性能三、我的项目成品成果 四 ,如果有什么须要的需要敌人能够分割我即可,欢送大家的交换和学习。

December 1, 2022 · 1 min · jiezi

关于im:融云推送服务独享推送通道更高并发能力应用运营必备

⬆️报名融云&艾瑞“政企数智办公钻研报告及新品发布会” 你的手机里一共装了多少 App?其中有多少下载后简直没再“光顾”?关注【融云寰球互联网通信云】回复【融云】抽取高颜值大容量高端可乐保温杯哦~ 有数据显示,挪动网民手机人均装置 App 总量曾经达到 74 个。 挪动互联网时代,咱们的生存、工作都能够搬到线上,挪动化发展。依据工信部数据,截至往年 5 月末,我国市场上已有 232 万款 App。 一体两面,App 利用市场迅速崛起,同质化竞争紧随其后。尤其在大热的社交泛娱乐赛道,巨头虹吸和翻新窘境夹击下,利用很容易陷入降落螺旋。在胜利吸引用户装置后,间接影响 LTV(客户一生价值)的便是留存和活跃度。正当应用推送服务,激活用户,唤醒 App 生命力就非常重要了。 推送是融云最早打造的通信周边能力之一。开发者只需集成一套融云 IM SDK,无需自行逐个对接多家手机品牌厂商,即可取得毫秒级触达指标用户的极致体验。在融云的全生态出海解决方案中,推送也是重要组件之一。融云笼罩 FCM、APNs 等零碎通道,并通过寰球通信网络,实现海内 App 推送的“使命必达”。无论是国内还是海内,推送音讯都是利用经营最间接无效且高性价比的形式。 首先,展示状态更间接,唤起形式更高效。 相比微信公众号、微博等须要关上 App 能力看到音讯的形式,推送音讯更间接。推送音讯达到手机终端时间接展现在手机终端的告诉栏内,音讯达到时能够设置声音、触动等多种揭示形式。 相比通过短信携带链接关上 App 的形式,推送音讯唤起率更高。用户点击音讯时能够设置拉起 App、关上网页等多种形式,更疾速高效。 其次,音讯类型更全面,经营老本更可控。推送音讯可蕴含文本、图片等多媒体文件,简直能够笼罩 App 经营的全副利用场景,推送内容可由开发者自定义编辑。 推送老本更低,如应用融云平台推送音讯,最低每月只需几百元,即可享受快捷、高速、稳固的推送音讯服务。 音讯推送的典型利用场景音讯推送分为告诉音讯和经营音讯两大类。告诉音讯个别指由用户被动操作或触发业务流程而发送的音讯,如:即时通讯音讯、物流音讯等; 经营音讯个别指由 App 运营者被动发动的音讯,如:流动告诉等。 告诉类音讯 即时通讯单聊、群聊、超级群等通信场景下产生的音讯,在用户未关上 App 时也能够对指标用户进行音讯揭示,包含文字、图片、语音、自定义音讯等。 游戏互动游戏组团邀请、游戏连麦邀请、1V1 聊天场景音视频呼叫告诉、语聊房连麦申请告诉、独唱邀请告诉等场景下,提供文本、富媒体、自定义音讯等推送形式,满足社交、游戏互动。 状态同步商品下单状态、物流告诉、快递派送告诉等状态同步,及时告诉用户,晋升服务满意度,升高客户征询频率,进步电商转化率。 ⏰ 服务告诉出行告诉、工作事项告诉、财务告诉、衰弱数据揭示等,可让用户及时获取重要信息。 经营类音讯 内容举荐资讯、游戏、视频类 App 须要对用户被动推送关注的内容或热点资讯,帮忙用户疾速获取感兴趣的信息,同时晋升 App 关上率,减少内容生产度,晋升用户活跃度。 用户拉活针对不沉闷的用户进行促活经营,如对新用户推送产品疏导、对低频应用用户举荐新性能、找回散失用户,通过定向被动地进行音讯推送,晋升客户活跃度。 促销流动在游戏流动、优惠促销等产品推广和营销流动中,通过对指标用户定向推送音讯,吸引用户参加流动、购买商品等,晋升营销流动转化成果。 零碎告诉新版本公布、产品更新等时刻,对用户进行定向告诉,促成用户降级或晋升用户活跃度。 融云推送 Plus 服务推送 Plus 是融云面向高并发推送需要开发者提供的增值服务。反对推送文本、富媒体、自定义音讯等,实用于社交互动、交易状态同步、系统升级、账号唤醒拉活、流动告诉等推送服务场景。 ...

November 22, 2022 · 1 min · jiezi

关于im:融云-IM-和-RTC-服务助攻智能物流等客户打通链路完善生态

⬆️关注公众号报名融云&艾瑞“政企数智办公钻研报告及新品发布会” 挪动互联网时代,通信技术曾经冲破传统劣势项“社交泛娱乐场景”的利用范畴,在不同的业务中大放异彩,起到买通链路的关键作用。关注【融云寰球互联网通信云】回复【融云】抽取高颜值大容量高端可乐保温杯哦~ 融云 IM 即时通讯和 RTC 实时音视频全矩阵产品,提供通信底层能力及 UI 组件残缺封装等多种产品交付模式,且反对开发者不便地集成推送、内容审核、翻译等罕用组件,让各类业务更快取得通信能力,晋升产品力。 通过多年摸索实际,融云曾经反对超过 30 万 App 取得了通信能力,其中不乏各类实用性产品利用。融云寰球通信云服务,助力多行业客户做深产品价值,晋升用户体验,打造丰盛生态。 智能物流:极智嘉“麻利响应”服务台,售后保障全天在线 在人力老本上涨、疫情防控常态化等多重压力下,机器人正减速落地于仓储、物流等场景。 极智嘉专一于智慧物流畛域,领有业内最丰盛的机器人产品线,聚焦仓储场景,具备存储、拣选和分拣的全计划能力。目前,极智嘉次要向大型工业制作公司、批发企业和第三方仓储物流公司提供各类仓储物流机器人和软件系统,寰球 AMR(自主移动机器人)市场占有率高达 10%。 集成融云 IM 即时通讯模块,极智嘉上线了 7 x 24 小时服务台,多音讯类型 100% 送达,构建连贯客户需要的第一战线,诠释牢靠、关心、高效的服务理念。在融云 IM 稳固的音讯通道反对下,客户音讯不丢、不重、不乱序,极智嘉得以在 10 分钟内实时响应服务申请,近程辨认故障并提供解决方案,确保客户服务需要失去及时无效解决。融云 IM 以稳固、牢靠的单群聊即时通讯能力,满足客户服务沟通场景需要。 反对文本、语音、视频、图片、自定义音讯等多种音讯类型,反对多语言翻译全量音讯路由性能,可将用户发送的音讯同步到应用服务器,便于对接后盾客户零碎,实现接单、调配等需要流转反对向单个用户、在线用户、指定标签及利用所有用户发送零碎告诉,灵便满足经营需要与业务体系完满交融,不影响客户现有的零碎架构与账号体系此外,融云通信云在大量业务实际根底上残缺封装相干服务,不仅提供稳固牢靠的通信能力,还提供聊天列表界面及聊天窗口,文本、语音音讯内容输入区,图片、视频、文件音讯扩大功能区等标准化的聊天界面 UI,让客户疾速实现相干能力。 面对寰球业务需要,融云不仅以笼罩寰球 233 个国家和地区的通信网络提供就近接入点,还提供国际化 UI,反对中文、英文、阿拉伯语等多语言 UI 切换,为寰球客户提供更好的应用体验。 护工服务:家护小助近程通信,护理工作“得力助手” 家护小助 App 是国内当先智慧城市解决方案提供商万达信息推出的护工治理平台。 万达信息与融云达成单干,买通家护小助 App 的用户端、医护端、治理端和护工挪动端,成为一个领有下单派单、路线指引、签到签退、近程通信、数据分析治理等多功能的业余护工治理平台。在集成融云 RTC 实时音视频服务后,服务机构和护工的工作都得以在近程通信的赋能下更加标准无效地推动。(点击理解详情) 医疗招聘:医脉同道“直聊+智能匹配”,垂直招聘的精准狙击 专为大健康人求职招聘打造的医脉同道 App,由国内首家登陆 A 股的人力资源服务企业科锐国内推出,集成融云通信云能力,打造“直聊+智能举荐”模式下的业余求职环境。在融云寰球通信云疾速、便捷的集成计划反对下,医脉同道 App 顺利上线,作为懂医药人的“同道中人”,帮忙专业人才在职业生涯中更好地倒退。 借由即时通讯,人才能够与招聘企业 HR 甚至用人部门高管开展直接对话,并在沟通中深刻理解岗位需要,晋升求职和招聘效率。(点击理解详情) 毋庸置疑,中国曾经处于挪动互联网倒退成熟期,线上化商业模式进入深水区。用户价值对于产品商业胜利的重要性越来越显著,倒逼各类产品和服务交融更多触达客户的能力,晋升服务体验。 这也让通信业务历久弥新,一直激活翻新力量,与业务碰撞出更多火花。技术能力继续精进、翻新产品步履不停,融云也将继续投入研发、打磨翻新内核,助攻更多客户的商业化胜利。

November 22, 2022 · 1 min · jiezi

关于im:小巨人大能量融云成功入选国家级专精特新小巨人企业

近日,北京市经济和信息化局公布《北京市经济和信息化局对于对第四批国家级专精特新“小伟人”企业和通过复核的第一批国家级专精特新“小伟人”企业名单进行布告的告诉》。《告诉》显示,融云作为专一于细分市场、创新能力强、市场占有率高、把握要害核心技术、品质效益优的排头兵企业,正式入选国家级专精特新“小伟人”企业名单。关注【融云 RongCloud】,理解协同办公平台更多干货。 中小企业爆发大能量 生机满满韧性强中小企业是我国经济继续倒退的重要根底,是保障市场失常运行、待业稳固的次要力量,是产业链要害畛域补短板、填空白的关键环节。 工信部数据显示,截至 2021 年底,全国中小微企业数量达到 4800 万家,奉献了全国 50% 以上的税收、60% 以上的 GDP、70% 以上的技术创新、80% 以上的城镇待业和 90% 以上的企业数量。而专精特新“小伟人”企业作为中国中小企业的优良代表,创新能力强、倒退韧性足,在推动中小企业高质量倒退中起着要害的示范和楷模作用。 8 月 30 日工业和信息化部举办了 “新时代工业和信息化倒退” 第三场系列新闻发布会,工业和信息化部中小企业局局长梁志峰在答复人民日报记者发问时指出,一共有 1.3 万家企业申报第四批专精特新“小伟人”企业,经审核公示的有 4300 多家企业。这些企业出现三大特点: 一是创新性强,研发投入高。企业均匀研发经费占营业支出比重 10.4%,均匀领有 I 类知识产权 16 项、发明专利 14 项。 二是专业化水平高,配套能力强。企业从事细分畛域工夫均为 3 年以上,其中 10 年以上的 3000 余家,是强链补链固链的生力军。 三是成长性好,发展潜力大。近两年,企业户均年均匀营业支出增长都在 20% 以上,增长态势显著。 专精特新“小伟人” 通信畛域排头兵专精特新,即专业化、精细化、特色化、新鲜化。 在专业化层面,融云团队具备近 20 年通信行业积攒,公司成立 8 年来始终专一于互联网通信云技术畛域。 先是开创性地将即时通讯技术封装为 SDK,破除社交赛道开发者面临的“即时通讯技术简单度过高”的难题,后又将同样的服务扩大至实时音视频,乃至推送、审核、美颜等,造成“IM 即时通讯 + RTC 实时音视频 + X 通信周边能力”的全通信解决方案。 融云以 API/SDK 模式提供的 PaaS 层通信能力,解决的是信息传递与沟通的根本问题,成为现在互联网社交交融、政企数字化转型、万物互联、虚拟现实等社会各大发展趋势背地的“新基建技术底座”。 截至目前,融云 SDK 触达用户数 73 亿+,日均音讯量 150 亿+,日音讯峰值 2218 亿+,日均沉闷数 7000 万+,累计服务几十万 App,以及几千家国家政府机关、企事业单位和各行业用户。艾瑞征询调研数据显示,融云间断多年在 IM 畛域市场占有率第一,实时音视频畛域位居第一营垒。 ...

November 2, 2022 · 1 min · jiezi

关于im:抢滩东南亚融云IM助力应用抓住经济转型红利

间隔 2022 年收官还剩 75 天,浅总结一下往年的互联网关键词,“降本”肯定是大写加粗名落孙山的。关注【融云寰球互联网通信云】理解更多 依据 Wind 数据,中国市值 Top20 的科技及互联网公司,上半年节俭了 133 亿元市场和管理费用。面对大环境的不确定性,这是杀伐果决的互联网公司们最确定和动摇的策略。另一个景象级动作是,互联网大厂仿佛都开始对线下生意热心起来了。 京东前阵子在沈阳开起了商场,还有网易云音乐的酒吧,字节的房产中介和医疗门诊,以及腾讯的潮玩店。可见降本的同时寻找新的增长曲线,是大家独特的抉择。 向线下走之外,到海内去也是大部分厂商抉择的增长曲线。而这其中,正在经验数字化降级的东南亚是离中国最近的价值高地。 东南亚十国人口 5.8 亿,其中互联网人口超过 4.2 亿,占比高达 72%。谷歌、淡马锡和贝恩联结公布的《2021 年东南亚互联网经济报告》显示,东南亚 2021 年的互联网经济规模无望达 1740 亿美元,年均复合增长率高达 49%。 往年 9 月,阿里云、华为云接连公布以东南亚为基地的出海打算,其背地逻辑就在于当地市场的科技守业和数字化降级催生出了微小的云需要。与国内蓬勃发展了二十多年,流量红利简直见顶的状况不同,东南亚仍在向线上看齐。近年来,东南亚守业潮低落,次要体现为以网约车、外卖、电商、招聘等生存类场景线上化和直播、语聊等娱乐场景线上化为外围的挪动互联网守业,以及人工智能、Web3、区块链守业。 把握数字化降级时机 商业如何与 IM 联合实现社交化东南亚的互联网市场及数字产业是目前寰球范畴的一个焦点。利用新技术的赋能,降维改革老生意的故事在美国硅谷、中国海淀轮流演出。当初,镜头切换到了东南亚,“印尼硅谷”之称正在被几个地区炽热抢夺着。 与此前的故事一模一样,智能硬件普及率和挪动化习惯的出场,预示着微小的市场空间。据 GSMA(寰球挪动通信协会)称,到 2025 年,东南亚的挪动数据消耗量将增长到三倍,从每位用户每月 9.2 GB 减少到 28.9 GB。 落子东南亚,无论是出于与国内市场一唱一和的策略补位思路,还是间接以指标区域市场为开始寻求全球化倒退,都须要减速推动产品社交化,抓住策略转型上升期中一代人的娱乐和生存线上化红利。在数字化倒退过程中,IM 与商业相结合,曾经冲破咱们传统印象中的熟人社交聊天场景,在不同的业务中大放异彩,起到买通链路的关键作用。 客服、营销、招聘场景的单群聊客服征询是简直所有商业线上化的必备环节,助力实现“流量-服务-转化”的闭环。 在营销方面,与发达国家的高人工成本不同,新兴经济体的经营能够将更多工夫花在通过 IM 与客户互动上。通过群聊建设本人的私域,向客户再次营销取得复购。 以 IM 为根底搭建服务平台,也是疫情之下线下场景线上化的实质性变动体现。比方,KUPU 以融云 IM 为外围能力构建线上招聘体系,通过让招聘单方在挪动端直接对话和自动化整个招聘流程,为线下实体提供更好、更高效的招聘服务。多样沟通 面试预约 直播、语聊房中的聊天室在娱乐方向上,IM 能力也是产品社交化的根本体现。在游戏利用中加上 IM 聊天等场景进步游戏体验,用户的应用时长和留存会失去显著晋升。 此外,有一些娱乐产品状态中 IM 是外围组件。比方,直播和语聊房中的聊天室。除了用户最可感可知的多类型音讯发送和治理外,直播聊天室还要承当用户治理等工作,应答人数无下限和海量音讯并发的挑战。 趣味社区、用户经营中的超级群得益于东南亚沉闷的互联网用户体现,电商无疑成了其数字化最亮眼的一个切面。疫情以来,东南亚新增电商消费者数量已达 7000 万人,线上生产需要猛增。 依据东南亚本地物流公司的报告,社交媒体、用户评估是东南亚消费者构建品牌与产品信息认知的次要起源,他们在购物后也非常乐于信息交互,公布反馈的比例高达 94%。 这一用户习惯是建设社区的最好根底,尤其是对一些兴趣爱好消费品类来说,通过超级群产品状态对用户进行长期经营将造成一个正反馈闭环。比方钓鱼、飞盘、宠物、潜水等消费者,能够在垂直 App 上看天气、购买产品,并在其延展进去的社区中针对不同趣味主题进行心得分享和相干探讨。 ...

October 18, 2022 · 1 min · jiezi

关于im:移动端IM产品RainbowChat专业版-iOS端-v60版已发布

对于MobileIMSDK MobileIMSDK 是一套专门为挪动端开发的开源IM即时通讯框架,超轻量级、高度提炼,一套API优雅反对UDP 、TCP 、WebSocket 三种协定,反对iOS、Android、H5、规范Java平台,服务端基于Netty编写。 工程开源地址是:1)Gitee码云地址:https://gitee.com/jackjiang/M...2)Github托管地址:https://github.com/JackJiang2... 对于RainbowChat► 具体产品介绍:http://www.52im.net/thread-19...► iOS端更新记录:http://www.52im.net/thread-27...► 全副运行截图:iOS端全副运行截图 (另:Android端运行截图 点此查看)► 在线体验下载:App Store装置地址 (另:Android端下载体验 点此查看)  RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级挪动端IM零碎。RainbowChat源于实在经营的产品,解决了大量的屏幕适配、细节优化、机器兼容问题(可自行下载体验:专业版下载安装)。* RainbowChat可能是市面上提供im即时通讯聊天源码的,惟一一款同时反对TCP、UDP两种通信协议的IM产品(通信层基于开源IM聊天框架  MobileIMSDK 实现)。 v6.0 版更新内容 此版更新内容【新增“一键已读、搜寻”等性能!】(更多历史更新日志): 1)[新增] 搜寻性能(反对好友、群聊、聊天记录搜寻(与微信逻辑一样));2)[新增] “聊天信息”界面中新增“查找聊天记录”性能;3)[新增] “群聊信息”界面中新增“查找聊天记录”性能;4)[新增] 首页音讯界面中,减少了“一键已读”性能;5)[bug] 解决了iOS16+“灵动岛”手机下,聊天界面性能面板和输入法显示的抵触;6)[优化] 优化了聊天界面中查看地位、名片音讯回来时会主动滚动到最初一行的问题。此版次要新增性能运行截图(更多截图点此查看):

October 12, 2022 · 1 min · jiezi

关于im:小程序轻松实现IM即时通讯多人聊天室

IM多人聊天室性能简介ZIM SDK 提供多人房间聊天性能,反对用户向房间内发送文本音讯或自定义音讯,实现了多人在线交换、同步分享。 多人房间聊天性能可利用于小班课或者会议室等场景,房间成员数量下限请参考 计费阐明。 IM房间治理性能的前提条件在实现“房间治理”性能之前,请确保: 已在 ZEGO 控制台 创立我的项目,获取到了接入 ZIM SDK 服务所需的 AppID、AppSign。ZIM 服务权限不是默认开启的,应用前,请先在 ZEGO 控制台 自助开明 ZIM 服务(详情请参考 项目管理 - 即时通讯),若无奈开明 ZIM 服务,请分割 ZEGO 技术支持开明。已集成 ZIM SDK,详情请参考 疾速开始 - 实现根本收发音讯 的 “2 集成 SDK”。实现IM多人聊天流程用户能够通过以下两种形式,创立房间并进入房间。 形式一:创立房间、退出房间:用户 A 调用 createRoom 接口,传入 ZIMRoomInfo 信息,即可创立并退出房间。其余用户调用 joinRoom 接口,传入由 A 创立的房间 roomID,即可退出房间。形式二:进入房间:用户 X 调用 enterRoom 接口,传入 ZIMRoomInfo 信息,如果 roomID 不存在,会主动创立一个房间而后进入。其余用户须要调用 enterRoom 接口,传入由 X 创立的房间 roomID,进入房间。房间内的用户,能够通过 sendRoomMessage 接口,向房间内发送音讯,详情请参考 收发房间音讯。 如果 roomID 已存在: 调用 createRoom 接口,会返回相干错误码,详情请参考 常见错误码。调用 enterRoom 接口,会间接进入此房间内。如果 roomID 不存在: ...

September 8, 2022 · 2 min · jiezi

关于im:开源精品-CNET-im-聊天通讯架构设计-FreeIM-支持集群职责分明高性能

FreeIM 是什么?FreeIM 应用 websocket 协定实现繁难、高性能(单机反对5万+连贯)、集群即时通讯组件,反对点对点通信、群聊通信、上线下线事件音讯等泛滥实用性性能。 ImCore 已正式改名为 FreeIM。 应用场景:好友聊天、群聊天、直播间、实时评论区、游戏。 FreeIM 解耦了通信与业务模块,让我的项目架构变得更加简略易保护,2017年的设计再过5年也不过时。 FreeIM 提供了一套永远不须要迭代更新的 ImServer 服务端,反对 .NET5.0、.NETCore2.1+、NETStandard2.0。 以及一套简略的 ImHelper API 提供给 业务端 应用,例如 ImHelper.SendMessage(a, b, 'hello world') 就能够实现 a -> b 发送音讯。 开源地址:https://github.com/2881099/FreeIM ⛳ 我的项目由来2017 年进敌人的公司救火,那个时候公司的人员架构、技术架构一团糟,例如通信模块,装备了几人的全职团队负责工作,痛点如下: 1、IM服务端代码臃肿不堪; 2、逻辑凌乱不堪,IM服务端代码蕴含了大量业务逻辑,例如聊天记录、订单数据,这原本应该是业务方的数据; 3、凌乱继续放大,IM服务端为了适应需要,一直减少业务协定,越来越像业务端; 4、沟涌老本巨高,IM服务端常常和业务方开怼,比方某业务到底以谁的数据为准; 5、通信协定失策,IM服务端应用原生Socket自定义通信协定,起初要保护 WebSocket 及 本人定义协定两套,常常产生音讯无奈传输的问题; FreeIM 架构的接入之后,遣散了 IM 团队,解决了业务与通信的职责抵触,简化了架构,升高了保护老本。经验 1年半的生产环境,整顿代码于 2018 年开源。 我是不是太卷了。。别急啊,他们是 java 团队,是不是霎时难受了⚡ 如何接入?dotnet add package FreeIM1、ImServer 服务端 一套永远不须要迭代更新的IM服务端,ImServer 反对 .NET6.0、.NETCore2.1+、NETStandard2.0public void Configure(IApplicationBuilder app){ app.UseFreeImServer(new ImServerOptions { Redis = new FreeRedis.RedisClient("127.0.0.1:6379,poolsize=5"), Servers = new[] { "127.0.0.1:6001" }, //集群配置 Server = "127.0.0.1:6001" });}2、WebApi 业务端 ...

August 29, 2022 · 2 min · jiezi

关于im:跨平台|融云-React-Native-IM-SDK-全新改版上线

猿桌派 EP2 曾就“跨平台还是原生?”话题演出过一次大型 PK,三位嘉宾都是端上的兄弟,一番争执下来根本都偏差了采纳跨平台解决方案。关注【融云寰球互联网通信云】理解更多 诚然,跨平台开发计划劣势显著,一套代码利用于多个平台,不仅节省成本,还能够提速增效,为不同平台的用户提供统一的应用体验,且便于前期的保护迭代。为了让开发者更方便快捷地集成 IM 模块,融云以全平台能力反对全技术栈开发,满足不同业务类型、不同业务场景的须要。在挪动端利用大暴发和“凡利用必社交”的当下,采纳 React Native(RN)框架集成 IM 即时通讯能力备受企业和开发者的青眼。 近期,融云对 RN IM SDK 进行了全新改版降级,接口设计更加简洁,并新增了超级群等能力,满足更多开发者的疾速高效集成需要。 更简洁的接口设计RN 是 Facebook(现名 Meta) 于 2015 年 4 月开源的跨平台挪动利用开发框架,反对 iOS、Android 两大平台。 RN 反对在 JaveScript 和 React 的根底上构建原生 App,这意味着每一个视图都和原生别无二致,一套代码完满适配 iOS 和 Android 设施。 对于挪动端业务,尤其是没有历史包袱的新利用,React Native 框架是业务开发的绝佳抉择。融云最近改版降级的 RN IM SDK 接口设计性能更加丰盛、接口更加清晰、集成更加简略、应用更加不便。 比方,当咱们要用 RN IM SDK 实现发送一条文本音讯的性能,旧版和新版代码示例如下图示。 旧版本: 新版本: 比照代码,咱们能够得出以下论断: 旧版: 开发者须要本人去构建音讯体对象;调用发送音讯接口时,开发者须要自行传入回调函数。新版: SDK 提供了创立音讯体对象的接口,开发者只需调用即可;调用发送音讯的 API 接口时,开发者无需传入回调函数,须要回调时能够独自设置监听。通过比照,咱们能够直观地感触到二者的差别,相比旧版 SDK 的繁琐流程和简单接口定义,新版 SDK 应用便捷、不容易出错、接口定义更清晰。 集成指引 融云跨平台 IM - React Native ...

August 11, 2022 · 1 min · jiezi

关于im:融云-IM-RTC-能力上新盘点

融云产品播报,盘点点滴致力,提高步履不停。关注【融云寰球互联网通信云】理解更多 融云 IM 即时通讯和 RTC 实时音视频 2022H1 外围能力上新盘点,换个切面整体察看融云产品力晋升门路。 请看具体报道—— 融云 IM 即时通讯能力上新重磅推出超级群服务,上线 IMKit Web SDK,进一步晋升了性能多样性及平台全笼罩。 SDK 能力超级群重磅上线超级群(UltraGroup)提供了一种新的群组业务状态,反对在群会话中创立独立的频道,超级群的音讯数据和群组成员反对分频道进行聚合,各个频道之间音讯独立。 利用场景:容许用户在超级社群中依据本人的趣味退出不同的频道,在海量信息中聚焦本人感兴趣的内容,是构建趣味社群、游戏社区、粉丝社群等大型用户经营社区利器。 超级群个性 群成员人数不设限App 内的超级群数量没有限度一个超级群里反对创立多个频道成员可在任意频道中发送音讯,频道间的音讯互相隔离反对单人/全体成员禁言反对为指定的群,或群频道设置免打搅平台及版本:iOS + Android + Web + 小程序,V5.2.0 版本起**减少 IM 聊天室与 RTC 音视频房间绑定接口** 聊天室与音视频房间绑定胜利后,只有音视频房间仍存在,则阻止聊天室主动销毁。 利用场景:聊天室具备主动销毁机制。在应用融云语聊房、直播业务的 App 中,可能会配合应用 IM SDK 的聊天室业务实现直播聊天、弹幕、属性记录等性能。这种状况下,能够思考将聊天室与音视频房间绑定,确保聊天室不会在语聊、直播完结前销毁,免得失落要害数据。 平台及版本:iOS + Android + Web + 小程序,V5.2.1 版本起 IMKit Web 端 SDKIMKit Web 端 SDK,囊括单群聊、零碎告诉能力,内含高品质 UI,提供文本、表情、图片、GIF、语音、视频、援用、文件、地位等多种内置音讯类型,并反对自定义音讯满足客户个性化的音讯发送、展现需要。 可满足开发者 Web 端疾速上线开展业务的需要。 IMKit Web 个性罕用会话列表性能全笼罩对会话音讯未读数解决、会话置顶、会话免打搅、全局音讯内容搜寻等罕用会话列表性能进行了 UI 封装,性能残缺,产品化水平高。 单群聊会话界面开箱即用提供标准化的一对一、多人群组 UI 聊天界面,封装了简单的音讯输出、内容展现逻辑等,开发者无需二次开发,开箱即用。 音讯类型残缺封装内置文本、表情、图片、语音、地位、GIF、小视频等各种音讯类型及 UI 展现解决逻辑,也可通过自定义音讯性能实现非凡的音讯发送、展现需要。 ...

July 27, 2022 · 2 min · jiezi

关于im:OpenIM重大升级群聊读扩散模型发布-群管理功能升级

新性能介绍(1)群布告展现编辑者信息和公布工夫;(2)展现群成员进群形式(搜寻进群,二维码进群,邀请进群);(3)群减少权限管制,群成员禁止/容许增加好友,禁止/容许查看群成员材料;(4)当集体昵称批改时,实时更新群昵称;(5)好友备注可删除,并多端同步;(6)群聊反对读扩散,个性:新进群成员能够看到历史音讯;群聊音讯服务端只存一份;(7)群主管理员可撤回群内音讯,不受工夫限度;做技术的敌人对于读扩散写扩散应该不生疏,无论是信息流、论坛、信箱,还是私聊、群聊、告诉,都能用到读写扩散。本文不解说技术细节,OpenIM基于推拉联合的读扩散次要解决群聊模式下音讯冗余存储,音讯实时性,以及新用户入群无奈查看新音讯的问题。群聊读扩散创立时指定工作群,这种群采纳读扩散模型,每个群有独立seq,群成员共享此seq,能大幅缩小群音讯冗余,且晋升音讯实时性。并为下一步的音讯按需加载机制做好铺垫。新用户入群能够查看历史音讯,对于办公场景十分有用。群布告群布告在聊天顶部提醒,并展现编辑者信息和公布工夫。进群形式查看群成员进群形式,通过某个渠道进群:搜寻进群,二维码进群,谁邀请进群。群权限管制群主/管理员设置群成员禁止/容许增加好友,禁止/容许查看群成员材料,爱护群成员隐衷群主管理员撤回群内音讯群主、管理员撤回其余成员音讯,不受工夫限度安卓端体验:https://www.pgyer.com/OpenIM我的项目成绩从服务端到客户端SDK开源即时通讯(IM)整体解决方案,能够轻松代替第三方IM云服务,并能依据业务需要高度自定义和二次开发,打造具备聊天、社交、办公性能的app。OpenIM持续领跑开源IM畛域,在宽广开发者的大力支持下,目前github star继续冲破。越来越多的开发者把OpenIM利用在社交,协同办公畛域。github地址:https://github.com/OpenIMSDK/...开发者核心:https://doc.rentsoft.cn/#/咱们的团队OpenIM是由IM技术专家打造开源即时通讯组件,目前github社区沉闷,star近万,排名遥遥领先,开发者7000人,OpenM力争开源IM我的项目No1,打造开源IM第一社区。反对Android、iOS原生开发,反对Flutter、uni-app跨端开发,反对小程序、React等所有支流web前端技术框架, PC反对Electron。重点利用在政务办公,社交,web3场景,所有皆可控,让OpenIM深刻到各行业。

July 23, 2022 · 1 min · jiezi

关于im:如何基于IM-SDK从零开发移动端聊天功能

IM即时通讯技术的倒退即时通讯(Instant Messaging)是一种基于互联网的即时交换音讯的业务。 实时聊天交互性能是市面上支流APP的重要性能之一,人们所相熟的就是微信,QQ的聊天音讯零碎,IM看似简略,技术开发绝非易事,海量并发,超低延时,音讯必达等高实时性需要须要泛滥技术的利用合体; 近几年,随着挪动互联网的深刻浸透和社交+的迅速倒退,IM衍生出了很多新的玩法,不仅仅利用于社交聊天场景,还呈现在电商、直播、客服等各种场景,正在被人们宽泛的利用。 调研数据显示:市面上60%以上的APP领有即时通讯能力,用户能够间接在app内跟其余用户实时聊天,有助于晋升app沉闷和用户体验。IM性能的实现已成为利用开发者们必修课程。 笔者从事IM开发工作十年无余,本文次要分享IM开发的3种实现形式,心愿对IM开发者有所帮忙。 IM即时通讯3种实现形式IM开发的3种实现形式别离为:1、开源代码 2、自研 3、集成IM SDK。开发者可依据我的项目状况进行抉择。 一个IM产品的落地,大体上能够分成三个重要局部:客户端开发,服务端开发,服务运维。 客户端开发:包含各平台的手机app、桌面软件,网页端,小程序端等。服务端开发:负责IM各种性能的实现,比方用户接入、关系链保护、收发音讯、文件图片存储、平安审核等。服务运维:一个长期经营的产品,必然须要一个持续性的运维过程,以保障IM服务端稳固牢靠,比方业务量上涨的扩容解决。 以上三局部,任何一部分从零到一的实现,都会有不小的难度,齐全自研对我的项目成员能力,以及资源投入的要求都比拟高。除了大型公司会齐全自研以外,个别都会采取援用开源代码,或者集成商业IM SDK的形式。上面总结一下这3种实现形式的区别。表:IM3种实现形式 \实现形式 比照维度开源代码自研集成商业IM SDK实现难度低高中性能扩展性依赖开源我的项目打算,绝对艰难不依赖内部条件,绝对简略依赖其它厂商,难度中等运维老本本人运维,老本高本人运维,老本高不须要本人运维上线周期中慢快适用人群集体体验研发能力较强的大公司中小型公司,集体工作室第一种实现形式:应用开源我的项目实现IM聊天实现IM性能最快的形式就是抉择开源我的项目,不仅是站在伟人的肩膀上,还可会集全社区的智慧进行疾速开发; 如何抉择IM的开源我的项目?我的项目性能的欠缺度和活跃度是次要参考的维度,依据过往教训我选取了两个还算不错的开源我的项目供大家参考。 1.MobileIMSDK我的项目地址:https://github.com/JackJiang2... MobileIMSDK是一个原创挪动端IM通信层框架,轻量级、高度提炼,历经8年、久经考验。是市面上惟一同时反对UDP+TCP+WebSocket三种协定的同类开源框架,反对iOS、Android、Java、H5,服务端基于Netty。 PS:须要留神的是该项目标H5端暂未开源,小程序与Uniapp也还在开发之中。 2.OpenIM我的项目地址:https://github.com/OpenIMSDK/... OpenIM的开创团队来自IM高级架构师 ,由IM/WebRTC专家团队开发,致力于用开源技术发明服务价值,打造轻量级、高可用的IM架构,不便开发者构建多种即时通讯及实时音视频互动场景。 借鉴开源我的项目适宜开发周期紧,无需太多定制化开发者,可帮忙开发者疾速实现IM性能。但性能个别绝对简略根底,且后续的性能扩大重大依赖开源我的项目的开发进度。如果对定制化性能需要比拟高,或者将来业务体量比拟大,倡议不要偷懒去应用这种形式。 对IM定制化要求高有研发能力的团队个别采取自研的形式,接下来会跟大家分享下自研过程中的技术难点和坑点。 第二种实现形式:自研实现IM聊天IM技术波及范畴很广,齐全自研对研发团队能力、资金投入要求都比拟高,研发周期也会拉的比拟长。为了避免错失商机,须要做好长期的布局。 如图:自研技术概览 咱们在自研IM过程中,也遇到了一些比拟辣手的技术难题,这里列出来给大家做个参考,比方 音讯的可靠性、有序性。高并发场景下的音讯实时推送,以及音讯拉取。音讯存储计划选型:应用读扩散还是写扩散。音讯未读数的精确计算。群回执音讯。异地多活。对这些问题感兴趣,也能够参考优良IM学习网站(即时通讯网:http://www.52im.net/)。 自研过程中,有些性能也能够间接应用市面上的成熟产品,比方文件存储,平安审核,音讯离线推送。以放慢研发步调。将来如果决定自研这部分性能,也能够很不便的替换掉,达到事倍功半的成果。 对于有经济和开发实力的企业,且业务预期客户体量大,倡议走自研的实现形式,合乎前期能力拓展、疾速迭代和稳固运维的布局。 但自研须要投入较大的人力、财力,倡议想要走自研的开发者,做好明确的开发布局,缩小不必要的损耗。 引入开源我的项目,无奈很好的扩大新性能,且运维简单,难以撑持将来的长期倒退;自研路线周期长,老本较高。 那有没有折中一点的计划呢?既能够疾速上线,又不必投入那么大的老本,还能够定制化需要。集成商业sdk则是最便捷的形式,这也是目前较支流的开发模式。当初sdk厂商都很成熟,很多公司会抉择此形式。 第三种实现形式:集成商业IM SDK实现IM即时通讯集成商业sdk具备以下劣势: 疾速落地IM产品,疾速上线,抢占市场。服务稳固,防止烦杂的运维工作。性能可扩大:减少新性能时,能够被动向sdk厂商提需要实现。相比自研,大幅降低成本。 ##IM即时通讯产品落地流程抉择集成商业sdk时,产品落地流程如下: 申请sdk厂商服务账号,获取账号秘钥,用于用户登录。开发业务服务后盾,用于计算登录鉴权信息。集成厂商sdk,开发应用程序(比方iOS利用、Android利用、小程序等)。 以收发音讯为例,各模块之间的交互流程如下: 由此可见,集成商业sdk的计划,只须要开发一个简略的业务后盾,而后集成sdk,开发本人的应用程序,即可疾速上线服务。 IM SDK 厂商举荐-即构 IM SDK以后市面上曾经有不少成熟的IM SDK厂商,在这里举荐一家不错的厂商--即构科技(https://doc-zh.zego.im/article/11598)。之前开发的直播产品接了即构的RTC SDK,整个接入过程很顺畅,近期因我的项目需实现即时通讯性能,同一厂商图不便抱着尝试态度接入ZEGO IM SDK,没想到很快就实现开发实现了。 ZIM反对所有支流平台,包含flutter和uniapp两大跨平台框架,减速产品上线。在音讯平安审核方面,他们采纳支流第三方平安厂商的服务,须要的审核性能根本都可能反对。 实时通信的我的项目随着业务一直倒退,对通信服务的高可用/高并发/低延时有更高的要求。之前应用他们的RTC产品,低提早业内当先体现很优良。IM产品我拿集成的Demo测试了下,端到端延只有几十毫秒。 即构的IM产品不仅反对根底的单聊/群聊性能,还反对音讯高并发量的房间聊天,官网数据显示:单房间人数反对到百万以上,适宜对房间人数要求高的场景应用。另外还有很新鲜的呼叫邀请性能,满足即时通讯的需要。 教训分享:基于即构ZIM实现即时通讯性能应我的项目需要笔者选用ZIM实现单聊场景音讯收发,仅有简略2步整个过程半天搞定。以下以自己的教训分享如何疾速实现单聊场景音讯收发。集成sdk过程感兴趣的小伙伴到即构官网查看(https://doc-zh.zego.im/article/11598),在此不赘述。 IM 的应用场景中比拟常见的是点对点音讯,这里咱们以安卓端收发文本音讯为例。 3步轻松实现即时通讯音讯收发1、初始化 IM SDK取得一个 ZIM 实例 zim = ZIM.create(appID, application);2、登录ZIM类比微信账号登录的操作,用来作为收发音讯的载体 void login(ZIMUserInfo userInfo,String token,ZIMLoggedInCallback callback)对应 UI 示例: ...

July 19, 2022 · 1 min · jiezi

关于im:重要即时通讯IM开源项目OpenIM关于版本管理及v230发布计划

越来越多的客户把OpenIM用到了生产环境,因为新个性继续迭代和bug修复,会波及到后续的降级计划,为了让大家后续从容应对,本文重点总结OpenIM对将来版本治理的思路和计划。同时,官网对于文档进行了全面更新,有局部端的文档须要在下周实现。 文档核心:https://doc.rentsoft.cn/#/ 版本治理OpenIM版本治理较为简单,波及到服务端版本,以及多端SDK版本。因为OpenIM的SDK底层应用golang实现,所以aar/framework和go core SDK(Open-IM-SDK-Core https://github.com/OpenIMSDK/...) 版本保持一致。而插件层会修复本身bug从而带来版本号的变动,所以插件也有本身的版本号。服务端和客户端SDK只须要大版本(版本号第一位数字)保持一致即可。 用例子阐明版本号治理 (1)比方go core SDK是2.0.1 (稳定版)(2)aar包2.0.1 aar和go core SDK版本保持一致;(3)flutter2.0.1+a 后面三位数保留统一, a b c 是修复本身bug后的版本号(4)app 本身版本独立,如2.11.2, 但须要在app外面减少一项,示意应用了SDK版本号为2.0.1+a go sdk版本(github Open-IM-SDK-Core tag) aar/framework版本 Flutter sdk版本 iOS sdk 版本 Android sdk 版本 js sdk 版本 uniapp 版本 app/pc版本2.0.1 2.0.1 2.0.1+1 后面和core放弃不变 2.0.1.1 后面2.0.1放弃不变 2.0.1.1 后面2.0.1放弃不变 2.1.0-beta.1后面和core保持一致 2.0.1和core保持一致 利用版本能够齐全独立,但须要展应用sdk具体版本信息。版本公布过程2.0.1-rc0 =》2.0.1-rc1 =》 2.0.1(稳定版) 我的项目成绩从服务端到客户端SDK开源即时通讯(IM)整体解决方案,能够轻松代替第三方IM云服务,并能依据业务需要高度自定义和二次开发,打造具备聊天、社交、办公性能的app。 OpenIM持续领跑开源IM畛域,在宽广开发者的大力支持下,目前github star继续冲破。越来越多的开发者把OpenIM利用在社交,协同办公畛域。在经营过程中也裸露并修复了代码的一些bug,因为应用场景宽泛,OpenIM越来越强壮,开源价值也凸显进去了。 github地址:https://github.com/OpenIMSDK/... 文档核心:https://doc.rentsoft.cn/#/ V2.2.0稳定版V2.2.0稳定版公布工夫:2022年7月1日 平台反对以下平台都反对音讯互通,SDK和服务端代码100%开源,采纳Apache-2.0 License协定,任何团队和集体都能够收费商用。demo次要展现SDK如何应用。商业版是OpenIM团队在开源的服务端和SDK根底上,开发带有UI性能残缺的IM产品 平台 SDK 及兼容性 源码 Demo 商业版Android 兼容android5.0及以上版本 100%开源 100%开源 有,针对付费客户凋谢iOS 兼容iOS 11.0及以上版本 100%开源 100%开源 有,针对付费客户凋谢Flutter 兼容flutter2.0及以上版本 100%开源 100%开源 有,针对付费客户凋谢Uniapp 100%开源 100%开源 有,针对付费客户凋谢Electron 100%开源 100%开源 有,针对付费客户凋谢小程序 100%开源 100%开源 无Web 100%开源 100%开源 有,针对付费客户凋谢Linux 100%开源 100%开源 无帐号性能性能 阐明帐号禁用 设置Token踢出状态,强制用户踢出帐号导入 把用户导入OpenIM用户在线状态 查问用户是否在线,以及具体哪些端在线查问帐号 查问帐号是否导入多端登录性能 阐明单平台登录 Android、iPhone、iPad、Windows、Mac 只能1端在线;Web 可10端同时在线音讯类型性能 阐明文本音讯 音讯内容是一般文本图片音讯 音讯内容为图片 URL 地址、尺寸、图片大小等信息表情音讯 表情音讯为开发者自定义语音音讯 语音数据须要提供时长信息,以秒为单位地理位置音讯 音讯内容为地理位置题目、经度、纬度信息文件音讯 音讯内容为文件的 URL 地址、大小、格局等信息,格局不限,不限度大小。短视频音讯 音讯内容为视频文件的 URL 地址、时长、大小、格局等信息,不限度大小。自定义音讯 开发者自定义的音讯类型,例如红包等模式的音讯零碎告诉音讯 蕴含内置的零碎告诉音讯和开发者自定义零碎告诉音讯Tips 音讯 包含群、好友、用户信息批改等Tips合并音讯 最大反对10条音讯合并清空所有音讯 革除集体的本地和服务端音讯图片视频文件 反对MinIO,cos,oss上传会话性能性能 阐明删除会话 反对删除本地;反对删除本地,同时删除服务端设置会话免打搅 设置会话免打搅,单聊 群聊置顶会话 置顶/勾销置顶设置性能性能 阐明设置全局免打搅 设置后能收到音讯,但不揭示音讯性能性能 阐明离线音讯 用户登录后退到后盾,当有用户给其发消息时,即时通信 IM 反对离线推送漫游音讯 在新设施登录时,将服务器记录(云端)的历史音讯存储进行同步,默认为全量同步。多端同步 多终端音讯同步,可同时收到音讯历史音讯 反对本地历史音讯和云端历史音讯音讯撤回 撤回投递胜利的音讯,撤回工夫由UI本人管制已读回执 查看单聊/群聊会话中对方的已读未读状态,对于群聊能够查看哪些人已读/未读音讯转发 将音讯转发给其余用户或群组@性能 群内 @ 音讯与一般音讯没有本质区别,仅是在被 @ 的人在收到音讯时,须要在 UI 上做非凡解决正在输出 反对离线推送 目前整合了个推、极光推送音讯删除 反对仅删除本地,或者同时删除本地和服务端音讯回复 反对对音讯进行回复本地音讯搜寻 反对搜寻好友,搜寻群组、群成员;搜寻音讯,依照会话分组阅后即焚性能 阐明私聊阅后即焚 在私聊时,单方都能够开启或者敞开阅后即焚状态,在阅后即焚开启后,对方已读后,能够开启30秒倒计时,单方删除 ...

July 14, 2022 · 2 min · jiezi

关于im:充值满赠IMRTCX-全通信服务回馈季开启

中国互联网曾经进入低红利期。关注【融云寰球互联网通信云】理解更多 获客老本攀升、用户增长加速,互联网利用守业面对更逼仄的市场和更强烈的竞争,降本增效和业务翻新成为有效应对策略。 融云作为深耕行业多年的通信云服务商,以弱小的生态服务能力和易用的产品模式,为开发者提供 IM+RTC+X “全”通信解决方案。在外围的 IM、RTC 底层通信能力之上,甄选行业当先生态搭档达成单干,为开发者打造一个蕴含审核、美颜、推送等通信周边能力的残缺服务生态,实现服务边界的拓展和服务形式的提效。开发者能够依据场景和市场需求抉择所需能力疾速构建利用,将更多工夫和精力放在产品打磨和玩法翻新上。 为回馈新老客户,融云近期推出“全服务,回馈季”流动,2022 年 6 月 22 日起至 8 月 31 日止,充值满肯定额度即可获赠相应档位服务,堪称性价比之王。 两种套餐,一样超值套餐一✔ 充值 5,000 元,获赠服务 2 选 1 RTC10 万分钟,时长 1 个月反对状态实时同步、时长计费精准、呼叫接听通顺、心跳机制、异样主动挂断、违规主动踢出。 审核3 种套餐可选可对文本、图片、语音、视频、音频流、视频流进行涉政、涉黄、违禁、未成年、隐衷等审核服务。 套餐二✔ 充值 20,000 元,获赠服务 6 选 2✔ 充值 50,000 元,获赠服务 6 选 3✔充值 100,000 元,获赠服务 6 选 4 RTC10 万分钟,时长 2 个月反对状态实时同步、时长计费精准、呼叫接听通顺、心跳机制、异样主动挂断、违规主动踢出。 审核3 种套餐可选可对文本、图片、语音、视频、音频流、视频流进行涉政、涉黄、违禁、未成年、隐衷等审核服务。 高级美颜时长 1 个月提供人脸美颜美型、精准磨皮、领有 200+ 贴纸,反对定制贴纸/滤镜性能,以及多种套餐服务。 推送 Plus1 万并发,时长 1 个月反对厂商推送渠道、多个推送场景、推送统计、极速触达用户,无效进步用户粘性、拉升用户活跃度。 营销流动反作弊时长 1 个月无效辨认羊毛党、黄牛党,进攻营销欺诈行为,联合设施危险辨认、黑产情报追踪,业务场景全流程布控。 欺骗引流账号辨认时长 1 个月基于设施危险、账号内容特色和行为特色,精准辨认挖人、欺骗、广告导流等多种欺骗行为。 流动规定流动工夫:2022 年 6 月 22 日起至 8 月 31 日止。参加流动的客户当月充值开明后,当月即可享受赠送的服务,充值后 3 个月内开明无效。本流动可通过线上充值、线下汇款等形式参加。充值前,请务必与您的商务经理确认流动参加资格;充值后,请及时与相应商务经理确认,经财务确认后即示意参加胜利。胜利参加的客户,请与商务经理分割沟通具体开明的赠送服务。本次流动优惠与其余折扣或优惠券流动不能共存。如果您是老客户且以后利用有欠费,本次充值费用会优先抵扣欠款,以残余金额额度参加对应档位流动。流动期间充值赠送,如有退费,则需将已抉择的服务折算为对应费用进行抵扣。本流动最终解释权归北京云中融信网络科技有限公司所有。一图看懂所有福利 ...

June 30, 2022 · 1 min · jiezi

关于im:揭秘得物客服IM全链路通信过程

导读: 从用户角度咱们看到的征询客服的过程,是机器人 -> 转人工 -> 评估。整个过程中人工会话是 IM 通信的外围。对于整个客服体系在用户端触达人工会话前会经验哪些过程呢?客服人员又是怎么保障精准又疾速地匹配到用户解答用户的纳闷诉求,接下来一探到底吧。先来看下客服会话和对接零碎的整体架构图,如下所示: 访客端: 用户触达端(c端),次要三个性能:人工会话、满意度评估、机器人会话客服端: 次要的对接平台有:章鱼一站式工作台(人工会话聊天)、机器人治理后盾(机器人对话相干)、工单工作台(与人工会话严密相连)、在线客服工作台(为人工会话服务)。想要客服可能接线到用户,并且能精确的调配给指定的客服,咱们开发了在线客服工作台,通过了服务工夫设置,人机交互,进线调配,排队溢出会话流程设置一系列规定。 1. 先从服务工夫设置说起1.1 得物客服服务工夫首先有:得物惯例服务工夫,只有在限度的服务区间内,能够进行人工会话征询,超出惯例服务工夫的征询能够进行机器人问答或者留言,人工客服上线后能够进行响应的解答。 惯例服务工夫: 工作日和周末早上八点到次日凌晨 非常规服务工夫: 当然除了惯例工夫还有非凡服务工夫设置,比方双十一、618等大促期间的用户流量减少,订单量减少在某一个时间段内服务工夫须要提前或者缩短时进行非凡设置。合乎非凡工夫进线工夫的状况也能够失常进线到人工客服。 2. 分流规定正如有网购教训进行过客服征询的大家所晓得的,想要征询的问题有下单前的疑难,下单后的疑难,对物流进度的疑难,对到货商品尺码色彩等问题的征询。 不仅这些,还有买不同的商品时候产生的针对性的问题比方:鞋类,化妆品,服装,包包手表, 3C类等等。这些问题都须要业余的客服进行解答,那就不能轻易调配一个客服去接线,所以在用户进线征询之前要先进线分流规定的匹配,这是一个简单的逻辑。 用户有从不同渠道来的,从配置维度先按渠道做一个辨别: 得物有哪些进线渠道?目前得物的进线渠道有多个,包含得物App和小程序等等。 依据渠道如何做进线调配?举例说明:比方从得物App的商品详情页进线客服 依据渠道(得物App)+起源(商品详情)+分流维度 +调配形式 能够调配到指定的客服组。(分流维度能够设置机器人优先规定) 3. 排队溢出规定如上所说合乎了进线工夫,又满足了渠道起源调配终于要进线到人工聊天了,然而来的略微晚了一步,假如只有10个客服,每个客服的同时接线量是10,刚好你是第101个怎么办了。一不小心就触发了排队规定。 3.1 排队流程为了防止客服接线到曾经来到期待的排队用户,首先要判断用户是否在客服页面,不在线的状况给用户push 排队行将完结的提醒,在线的状况失常进入排队进线流程。 App端排队进线示意图: 3.2 溢出留言客服业务顶峰大量征询排队的时候,会呈现排队量不平衡,无奈调控。为了确保各组排队量、用户期待时长平衡,通过溢出规定,正当调配人工客服资源。 3.3实时数据监控在监控大屏有监控数据保留排队人次,来回进出保留队列只计算一次,然而如果用户屡次进线产生屡次排队,则计算屡次。 实时数据: 为当日数据。依据所选客服组查看不同队列的保留排队人次 依据监控正在排队人数和排队时长判断用户行为和客服接线能力是否合乎以后用户数量 4. 进线人工客服通过后面一系列的规定匹配进线调配,终于来到了人工会话,到了人工客服聊天的阶段,客户和咱们的客服是怎么进行聊天交互的呢?用过得物App的且征询过人工客服的同学应该都晓得客户端的应用状况那么客服是怎么接线怎么跟用户沟通的呢?前后咱们开发了两代零碎。 4.1 在线客服零碎这个零碎是IM客服零碎的第一代零碎,性能不仅包含在线聊天,聊天相干的配置用户治理都这里对立治理。 4.2 章鱼一站式工作台也就是当初客服应用的一站式工作台。因为客服聊天不仅要精确疾速,还有简单的会话切换信息缓存等等 和配置相干放在一起会影响客服的应用,进而开发了章鱼一站式工作台,专供客服接线相干的性能应用。 三栏布局的模式: 左侧区域: 在线、离线、留言用户列表 两头聊天区域: 会话内容,客服聊天区域,包含表情、图片视频邀评等等发送的性能右侧区域: 用户相干的信息功能区,包含用户信息、得物先知、订单查问、创立工单(工单数据会同步在工单零碎便于对工单专门解决),商品举荐。4.2.1 数据的触达双端的过程数据次要包含了一般文本音讯、富文本、图片、视频、文件等等。保障音讯能精确的实时的送达到客服和客户端长链接是一个不错的抉择 , 这些数据先到后端-后端推给 网关 -网关通过长链推送到 章鱼工作台,以后长链接可用的状况下,每一次申请都只是简略的数据发送和承受。 说到这里,大家可能会有疑难,如果发送音讯过程中呈现了 网络 抖动等问题导致问题无奈触达怎么办? 目前客服零碎用的ACK三次重连机制,在肯定工夫内如果没有收到网关的返回会进行重试,进行三次重连确保在有偶发的意外网络等情况时音讯可能发送胜利。同时为了防止继续重试,大面积重试造成网络梗塞三次尝试之后仍然失败的会显示发送失败。音讯不落库。 4.2.2 坐席辅助能力SOPSOP,是 "Standard Operating Procedure" 三个单词中首字母的大写 ,即规范作业程序,指将某一事件的规范操作步骤和要求以对立的格局形容进去,用于领导和标准日常的工作。 ...

June 30, 2022 · 1 min · jiezi

关于im:想秀你就秀环信MVP招募计划正式启动诚邀您加入

如果您有一颗乐于分享、专一IT技术的心,如果您领有过硬的IT技术及丰盛的技术教训, 如果您不甘心就此被湮没,环信 MVP 期待您的退出,总有些人会因您的退出而不一样!以下内容高能出没,请关注咱们的“十大权利”!环信MVP 技术博主、资深程序员、课程讲师爱玩、会讲、短少机会、喜爱挑战的你!!!环信 MVP 大舞台 有才你就来~~ 福利● 凡报名通过筛选的用户,即可取得环信定制T恤一件(截止至12月31日)● 转发此文章到朋友圈,并截图发给"环信小助手(冬冬)huanxin-hh",随机抽取2名用户赠送技术书籍(截止至12月31日) 退出咱们你将取得:你能够取得环信讲师贴心大礼包(环信定制双肩包、定制卫衣)讲师包装,打造明星讲师,晋升讲师在行业、社区中的知名度和影响力;您的技术干货、文章,咱们第一工夫举荐到环信官网或公号;评比年度环信优良讲师名称,颁发荣誉证书及奖品福利;你能够有机会被受邀做环信寰球音讯云大会演讲嘉宾并与业内技术专家面对面交换沟通;你能够领有本人的品牌公开课,晋升集体技术品牌影响力,向千万技术用户展现本人,领有本人的粉丝;你能够代表企业身份,向潜在用户具体解读本人企业的技术产品;你能够进步授课分享教训。你能够为企业招募到优秀人才;你能够优先取得由环信发放的定制或其余礼品; 咱们心愿你:1、扎根在一线技术专家,在某一技术畛域有至多 3-5 年实战我的项目教训,酷爱IT技术。2、热衷于互联网上分享技术教训,解答技术难题的IT精英;3、曾在公开行业技术会议中负责过演讲嘉宾,或出版过技术类滞销书籍作者。4、有肯定的演讲教训,讲课格调轻松、有趣风趣。5、普通话规范,逻辑清晰。 如果你是,或者你身边有这样的人,请顺手把这篇文章发给Ta。欢送成为咱们的MVP,与咱们一起让技术扭转世界~~ 环信MVP:https://www.easemob.com/mvp申请成为环信MVP:https://www.wjx.cn/vj/PZtCJSQ... 如有疑问请分割邮箱:carrie.xu@easemob.com 或者增加小助手微信征询:huanxin-hh(冬冬)

June 13, 2022 · 1 min · jiezi

关于im:深度剖析圈组关系系统设计-圈组技术系列文章

导读:网易云信新晋的 IM 顶流产品「圈组」出道后获取到了极大的关注,很多云信的客户在接入的同时对于「圈组」的底层技术细节和原理也十分关注,为此,咱们决定推出云信「圈组」相干的系列技术文章,分享网易云信在「圈组」技术设计上的一些思考。 业务特点在互联网行业流行一句话,技术是为业务服务的。具体到实际中,一个重要方面就是要面向业务特点设计技术计划。因而,想要理解「圈组」的关系零碎设计,就要首先理解「圈组」的关系业务特点。 「圈组」的关系业务特点是什么?其一是关系简单,即关系主体多、管理机制杂、联动耦合重;其二是规模微小,即成员数量可达百万量级、变更批量可达百万量级。 所谓关系简单,具体来讲:首先是关系主体多。在「圈组」业务中,关系主体包含服务器、频道、身份组、频道分组等,服务器承载社群关系,负责社群成员关系保护;频道从属于服务器,承载内容关系,负责内容互动关系保护;身份组可从属于服务器或频道,承载身份权限关系,负责身份设定和权限配置;频道分组从属于服务器,又关联一组频道,承载频道模版关系,负责分类频道和共享配置。其次是管理机制杂。在「圈组」业务中,仅就成员管理机制而言,服务器成员采纳邀请/申请机制,频道成员采纳公开/私密模式+黑/白名单机制,身份组成员采纳退出/移出机制,频道分组成员与频道成员采纳同步机制。最初是联动耦合。在「圈组」业务中,以频道成员保护为例,频道成员不仅受到公开/私密模式+黑/白名单配置变更的影响,而且会随同服务器成员变更、身份组变更、身份组成员变更等做联动变更。 所谓规模微小,具体来讲:一方面是成员数量可达百万量级。在「圈组」业务中,服务器成员数量能够达到数百万人,进一步,百万成员服务器下的频道和身份组,其成员数量也能够达到百万量级。另一方面是变更批量可达百万量级。在「圈组」业务中,不仅成员数量规模微小,而且变更操作一个批次数量也能够达到百万量级。包含:删除百万成员的服务器/频道/身份组,增删频道/频道分组黑白名单中的百万成员身份组等。 从「圈组」关系业务的两大特点登程,能够发现「圈组」关系是不同于群组关系的全新业务场景,将会面临全新的技术难点。 技术难点「圈组」关系零碎的技术难点次要有两个方面。其一是多关系主体、多管理机制在层级构造下关联耦合导致的业务逻辑的复杂性;其二是成员数量、变更批量规模微小导致的业务解决在工夫、空间、资源等开销上的复杂性。 业务逻辑复杂性首先「圈组」有多级构造。包含服务器/频道二级构造、服务器/频道分组/频道三级构造等。单个关系主体变更,不仅波及本身的变更,而且波及上下级关系主体的变更,能够说牵一动员全身。相比而言,群组是没有层级的,群组变更只有独善其身就好。 其次「圈组」有身份组。一个身份组是一组有独特权限的服务器成员的汇合,不同身份组的成员能够互相穿插,身份组会作为整体参加到成员治理中。也就是说,成员变更不再只是个别成员(1-100人)的进入退出,将会呈现整组成员(1-1000000人)的大进大出。相比而言,群组是没有身份组的,群组非凡成员包含群主、管理员等也都数量不多、互不反复。 最初「圈组」有多种成员管理机制。服务器成员和身份组成员的管理机制与群组相似,频道成员和频道分组成员的管理机制却是全新模式。频道分为公开和私密两种,公开模式默认容许所有服务器成员可见,但要排除黑名单身份组和黑名单成员;私密模式默认不许所有服务器成员可见,但要放开白名单身份组和白名单成员。除了受到公开/私密模式+黑/白名单配置变更的影响,频道成员也受到所依赖的关系主体(服务器成员、身份组、身份组成员)变更的影响。进一步,频道成员还受到所同步的频道分组变更的影响。相比而言,群组成员的邀请/申请机制,能够说是小巫见大巫。 业务解决复杂性首先是成员数量规模微小。因为成员数量可达百万,整个成员列表的存储空间开销、网络传输开销,变得非常微小,不管全量成员列表数据的服务器缓存,还是全量成员列表数据从服务器到客户端的同步,都将变得难以实现。 其次是变更批量规模微小。单次接口调用的关系变更,可能随同百万规模的联动关系变更,这会导致微小的解决工夫开销、计算资源开销,不管所有变更同步实现解决,还是所有变更单机实现解决,都将变得难以实现。 最初是告诉音讯规模微小。关系零碎不仅须要做关系变更的数据处理,而且须要告诉变更后果到客户端。因为在「圈组」中各个关系主体的成员数量规模微小,使得单个变更须要扩散为百万告诉同时下发,所需计算资源开销、网络传输开销非常微小。 相比而言,群组计划因为成员数量、变更批量规模无限,并不波及这些技术难点。 从「圈组」关系零碎的两个方面技术难点登程,能够发现「圈组」关系零碎面临不同于群组的全新技术难点,想要解决这些技术难点,须要翻新的技术计划。 技术分析「圈组」关系零碎是整个「圈组」计划的重要组成部分,在具体介绍「圈组」关系零碎技术计划之前,有必要首先理解「圈组」计划的整体架构。 「圈组」整体架构 下面展现了「圈组」计划的整体架构,能够看到「圈组」整体是一个分层架构。从上到下看: 客户层:包含可供客户端集成的挪动端、桌面端、跨平台 SDK,和可供服务器调用的 OpenAPI。接入层:包含 LBS 服务、长连贯服务和 API 网关,别离对应客户端 SDK 和用户服务器。网络层:包含自研的寰球实时传输网络 WE-CAN。业务层:包含用于 SDK 业务解决的 App 服务和用于 OpenAPI 业务解决的 WebServer 服务。服务层:划分有登录、音讯、关系、身份组、反对等服务模块,每个服务模块包含有多个微服务或消费者。基础设施层:包含零碎所用的数据库和中间件。关系零碎架构 关系零碎技术细节在「圈组」关系零碎中,上面具体探讨三个计划要点的技术细节,包含频道成员关系治理、变更告诉在线播送和关系数据云端检索。 频道成员关系治理频道成员关系治理,是「圈组」中极具挑战性的问题。频道成员波及多关系主体、多管理机制、联动变更耦合重大,成员数量和变更批量规模微小,能够说是「圈组」关系业务的典型代表。频道成员关系治理在业务逻辑和业务解决两方面的复杂性可想而知。针对频道成员关系治理问题,「圈组」设计了两大机制加以解决。包含:终态保护与过渡计算相结合机制、事件按序异步并行处理机制。 终态保护与过渡计算相结合机制,具体来讲,频道成员关系数据最终被保护在长久化数据库中,并在频道成员没有变更的终态阶段,间接反对频道成员数据的查问需要。当频道成员产生变更时,因为变更逻辑和变更解决两方面的复杂性,实现关系变更须要一段时间,称之为过渡阶段。在过渡阶段,数据库长久化的频道成员表数据是不齐全精确的,无奈间接反对频道成员数据的查问需要。此时转为由频道成员配置元数据间接计算频道成员以反对查问需要。因为频道成员配置元数据的变更是同步解决的,所以在过渡阶段由频道成员配置元数据间接计算频道成员能够保障查问准确性。通过将频道成员关系治理分为终态和过渡两个阶段,并在不同阶段采纳不同频道成员查问计划,不仅解决了单纯由计算获取频道成员资源开销大的问题,而且解决了频道成员变更提早导致由数据库获取频道成员后果不精确的问题。 除了频道成员的获取查问问题,频道成员的变更解决也很重要。事件按序异步并行处理机制,就是用于解决频道成员的变更解决问题。其一通过将影响频道成员关系的变更操作分层级、系统化定义为变更事件,显著升高频道成员关系治理的业务逻辑复杂性。其二通过 ID 哈希、分布式锁、事件版本号管制等保障变更事件的按序解决,无效防止事件处理乱序导致的长久化数据谬误。其三通过音讯队列直达事件并在消费者上异步解决,无效解决联动变更批量过大导致接口调用阻塞的问题。其四通过在单个事件处理中的多线程并行减速和本地缓存重用减速,显著缩短频道成员关系变更的时间延迟。 变更告诉在线播送关系零碎不仅须要做关系变更的数据处理,而且须要告诉变更后果到客户端。在百万量级的「圈组」关系中,每条关系变更告诉,都会面临海量扩散的接收者。除了告诉散发量激增,不同接收者对于告诉接管的缓急差别也值得关注。针对变更告诉在线播送问题,「圈组」设计了两大机制加以解决。包含:变更分类告诉机制、数据告诉拉取机制。 在变更分类告诉机制中,一方面,依据相干人员在变更中的角色,划分为参与者和观察者分类做告诉,即参与者肯定告诉,观察者依照订阅需要告诉。其中参与者个别是变更中的多数要害人员,观察者则是除了参与者之外能够看到变更后果的其它人员。通过分类告诉,不同接收者对于告诉接管的缓急差别失去正当关注,变更告诉的扩散规模也失去精准放大。另一方面,观察者依照订阅需要告诉,能够充分发挥「圈组」的在线播送订阅模式的劣势。所谓在线播送订阅模式,是指在用户登陆之后,须要订阅感兴趣的服务器/频道的告诉,「圈组」零碎会记录下这些订阅信息,当有新的告诉时,「圈组」零碎通过订阅关系而非成员列表 + 在线状态获取须要在线播送的用户列表,从而不再须要遍历服务器/频道的所有成员及其在线状态。通过采纳在线播送订阅模式,不仅显著升高变更告诉在线播送的计算开销和带宽开销,而且能够实现变更告诉在线播送在长连贯服务集群的并行减速和程度扩大。 变更告诉的最终目标是将变更后的数据给到客户端。不同于群组,「圈组」并不将变更后的数据间接由告诉带给客户端,而是采纳告诉客户端有变更再触发客户端拉取后果数据的机制。究其原因,不同于群组将关系数据全量同步到客户端,「圈组」客户端不再存储关系数据的全量镜像,因而不再须要通过全量历史 + 增量变更的形式保护客户端上的关系数据全量镜像。与此同时,订阅变更告诉的观察者也并不是每时每刻都要关怀变更的后果数据,关怀某次变更后果数据的观察者相比订阅变更告诉的观察者在数量上会少很多,因而,数据告诉拉取机制会显著升高变更告诉的资源开销。另外,相比带变更数据告诉,只告诉有变更,便于间接合并雷同类型的告诉,而不必关怀合并变更数据存在的时序、并发等问题,如此,数据告诉拉取机制能够通过短时间内告诉合并显著升高服务器在线播送开销和客户端告诉接管开销。 关系数据云端检索在「圈组」中,随同关系规模的大幅增长,群组基于应用服务器全量查问关系数据或客户端全量同步关系数据实现精准查问和灵便排序的计划不再实用。对此,「圈组」采纳了关系数据云端检索的计划。 「圈组」关系数据云端检索计划能够反对服务器、频道、成员等的检索能力。从检索场景上分,包含广场检索和外部检索。 广场检索:用于检索感兴趣的服务器。能够依据名称、类别等多种维度检索。检索后果能够依据预约义字段(成员数量等)或自定义值(数据热度等)等进行排序。 外部检索:用于检索用户可见的服务器、频道、成员等。能够依据名称、昵称等多种维度检索。检索后果能够依据预约义字段(创立工夫等)或自定义值(数据热度等)等进行排序。 总结说了这么多,云信「圈组」作为一款全新设计的产品,没有任何历史包袱的限度(然而却能够充沛排汇历史长处),你能够应用它构建一个类 Discord 产品,或者任何你想得到的社交/娱乐/游戏产品,欢送大家抉择。

June 10, 2022 · 1 min · jiezi

关于im:im即时通讯开发消息模型万人群已读回执消息撤回功能

企业微信作为一款办公协同的产品,聊天音讯收发是最根底的性能。音讯零碎的稳定性、可靠性、安全性尤其重要。 音讯零碎的构建与设计的过程中,面临着较多的难点。而且针对toB场景的音讯零碎,须要反对更为简单的业务场景。 针对toB场景的特有业务有: 1)音讯鉴权:关系类型有群关系、同企业共事关系、好友关系、团体企业关系、圈子企业关系。收发音讯单方需存在至多一种关系才容许发消息; 2)回执音讯:每条音讯都需记录已读和未读人员列表,波及频繁的状态读写操作; 3)撤回音讯:反对24小时的有效期撤回动作; 4)音讯存储:云端存储时间跨度长,最长可反对180天音讯存储,数百TB用户音讯需优化,缩小机器老本; 5)万人群聊:群人数下限可反对10000人,一条群音讯就像一次小型的DDoS攻打; 6)微信互通:两个异构的im零碎间接买通,可靠性和一致性尤其重要。 整体架构分层如下。 1)接入层:对立入口,接管客户端的申请,依据类型转发到对应的CGI层。客户端能够通过长连或者短连连贯wwproxy。沉闷的客户端,优先用长连贯发动申请,如果长连失败,则选用短连重试。 2)CGI层:http服务,接管wwproxy的数据包,校验用户的session状态,并用后盾派发的秘钥去解包,如解密失败则拒绝请求。解密胜利,则把明文包体转发到后端逻辑层对应的svr。 3)逻辑层:大量的微服务和异步解决服务,应用自研的hikit rpc框架,svr之间应用tcp短连进行通信。进行数据整合和逻辑解决。和内部零碎的通信,通过http协定,包含微信互通、手机厂商的推送平台等。 4)存储层:音讯存储是采纳的是基于levelDB模型开发msgkv。SeqSvr是序列号生成器,保障派发的seq枯燥递增不回退,用于音讯的收发协定。 发送方申请后盾,把音讯写入到接管方的存储,而后push告诉接管方。接受方收到push,被动上来后盾收音讯。 不重、不丢、及时触达,这三个是音讯零碎的外围指标: 1)实时触达:客户端通过与后盾建设长连贯,保障音讯push的实时触达; 2)及时告诉:如果客户端长连贯不在,过程被kill了,利用手机厂商的推送平台,推送告诉,或者间接拉起过程进行收音讯; 3)音讯可达:如果遇到音讯洪峰,后盾的push滞后,客户端有轮训机制进行兜底,保障音讯可达; 4)音讯防丢:为了避免音讯失落,只有后盾逻辑层接管到申请,保障音讯写到接管方的存储,失败则重试。如果申请在CGI层就失败,则返回给客户端出音讯红点; 5)音讯排重:客户端在弱网络的场景下,有可能申请曾经胜利写入存储,回包超时,导致客户端重试发动雷同的音讯,那么就造成音讯反复。为了防止这种状况产生,每条音讯都会生成惟一的appinfo,后盾通过建设索引进行排重,雷同的音讯间接返回胜利,保障存储只有一条。 扩散读 即:每条音讯只存一份,群聊成员都读取同一份数据。 长处:节俭存储容量。 毛病: ① 每个用户需存储会话列表,通过会话id去拉取会话音讯; ② 收音讯的协定简单,每个会话都须要增量同步音讯,则每个会话都须要保护一个序列号。 扩散写 即:每条音讯存多份,每个群聊成员在本人的存储都有一份。 长处: ① 只须要通过一个序列号就能够增量同步所有音讯,收音讯协定简略; ② 读取速度快,前端体验好; ③ 满足更多ToB的业务场景:回执音讯、云端删除。 同一条音讯,在每个人的视角会有不同的体现。例如:回执音讯,发送方能看到已读未读列表,接受方只能看到是否已读的状态。云端删除某条群音讯,在本人的音讯列表隐没,其他人还是可见。 毛病:存储容量的减少。 企业微信采纳了扩散写的形式,音讯收发简略稳固。存储容量的减少,能够通过冷热拆散的计划解决,冷数据存到便宜的SATA盘,扩散读体验稍差,协定设计也绝对简单些。 1)每个用户只有一条独立的音讯流。同一条音讯多正本存在于每个用户的音讯流中; 2)每条音讯有一个seq,在同个用户的音讯流中,seq是枯燥递增的; 3)客户端保留音讯列表中最大seq,阐明客户端曾经领有比该seq小的所有音讯。若客户端被push有新音讯达到,则用该seq向后盾申请增量数据,后盾把比此seq大的音讯数据返回。 高峰期零碎压力大,偶发的网络稳定或者机器过载,都有可能导致大量的零碎失败。im系统对及时性要求比拟高,没方法进行削峰解决。那么引入一些柔性的策略,保证系统的稳定性和可用性十分有必要。 具体的做法就是启动过载爱护策略:当svr曾经达到最大解决能力的时候,阐明处于一个过载的状态,服务能力会随着负载的增高而急剧下降。如果svr过载,则回绝掉局部失常申请,避免机器被压垮,仍然能对外服务。通过统计svr的被调耗时状况、worker应用状况等,断定是否处于过载状态。过载爱护策略在申请顶峰期间起到了爱护零碎的作用,避免雪崩效应。 解决方案思路就是:只管失败,也返回前端胜利,后盾保障最终胜利。 为了保障音讯零碎的可用性,躲避高峰期零碎呈现过载失败导致前端出红点,做了很多优化。 具体策略如下: 1)逻辑层hold住失败申请,返回前端胜利,不出红点,后端异步重试,直至胜利; 2)为了避免在零碎呈现大面积故障的时候,重试申请压满队列,只hold住半小时的失败申请,半小时后新来的申请则间接返回前端失败; 3)为了防止重试加剧零碎过载,指数时间延迟重试; 4)简单的音讯鉴权(好友关系,企业关系,团体关系,圈子关系),耗时重大,后盾稳定容易造成失败。如果并非明确鉴权不通过,则幂等重试; 5)为了避免作恶申请,限度单个用户和单个企业的申请并发数。例如,单个用户的耗费worker数超过20%,则间接抛弃该用户的申请,不重试。 优化后,后盾的稳定,前端根本没有感知。 零碎稳定性设计2:零碎解耦 因为产品状态的起因,企业微信的音讯零碎,会依赖很多内部模块,甚至内部零碎。 例如:与微信音讯互通,发送音讯的权限须要放到ImUnion去做断定,ImUnion是一个内部零碎,调用耗时较长。 再如:金融版的音讯审计性能,须要把音讯同步到审计模块,减少rpc调用。 再如:客户服务的单聊群聊音讯,须要把音讯同步到crm模块,减少rpc调用。为了防止内部零碎或者内部模块呈现故障,连累音讯零碎,导致耗时减少,则须要零碎解耦。 咱们的计划:与内部零碎的交互,全设计成异步化。即时通讯聊天软件开发能够征询蔚可云。 思考点:须要同步返回后果的申请,如何设计成异步化? 例如:群聊互通音讯需通过ImUnion鉴权返回后果,前端用于展现音讯是否胜利发送。先让客户端胜利,异步失败,则回调客户端使得出红点。 如果是非主流程,则异步重试保障胜利,主流程不受影响,如音讯审计同步性能。那么,只须要保障外部零碎的稳固,发消息的主流程就能够不受影响。 零碎稳定性设计3:业务隔离 企业微信的音讯类型有多种: ...

May 7, 2022 · 1 min · jiezi

关于im:千亿级IM独立开发指南全球即时通讯全套代码4小时速成三

本文篇幅较长,共计19352字,预计浏览时长1-2h。 这是《千亿级IM独立开发指南!寰球即时通讯全套代码4小时速成》的第三篇:《APP 外部流程与逻辑》系列文章可参考:《千亿级IM独立开发指南!寰球即时通讯全套代码4小时速成(一)》:Demo演示与IM设计《千亿级IM独立开发指南!寰球即时通讯全套代码4小时速成(二)》:UI设计与搭建《千亿级IM独立开发指南!寰球即时通讯全套代码4小时速成》4:服务端搭建与总结(行将凋谢) 三、APP 外部流程与逻辑1. 数据库操作作为即时通讯的App,将会有很多的数据须要本地存储。比方联系人的信息,聊天的历史音讯。假如如果每次都是从网上实时拉取对话的历史聊天记录,当一个延绵不绝的会话超过1个月以上时,比方,你和你好友的会话,那海量的聊天记录,不经工夫漫长,而且还会让用户的带宽苦楚不已~~ 所以,咱们将应用数据库保留联系人信息和聊天记录。对于数据库的抉择,一贯是够用就行,第三方依赖越少越好。刚好iOS自带SQLite,作为数据库的新手,咱们决定间接应用SQLite,至于SQLite.swift这个出名的第三方库,目前感觉至多在这个Demo中,没有应用的必要。 1.1 增加SQLite库 关上我的项目属性页面,抉择“TARGETS” -> “IMDemo” -> “General”: 点击页面上 “Frameworks, Libraries, and Embendded Content” 栏下方的“+”号,关上框架与库增加窗口: 在搜寻框内输出“SQLite”,抉择“libsqlite3.tbd”,点击“Add”按钮进行增加。增加结束后,“Frameworks, Libraries, and Embendded Content” 一栏显示为: 1.2 初始化数据库 增加 swift 代码文件 DBOperator.swift,编辑代码如下: class DBOperator { var db: OpaquePointer? init() { db = nil } deinit { if db != nil { sqlite3_close(db) } } func openDatabase(userId:Int64) { //-- TODO }}因为每个用户的数据须要隔离,所以最简略的形式便是每个用户应用一个独立的数据库。因而咱们无奈在App一起动的时候便关上数据库,而须要等到登录胜利后,获取到了用户惟一的 userId,才可晓得,该为谁关上数据库,应该关上那个数据库。 因而,咱们实现 openDatabase() 的代码如下: func openDatabase(userId:Int64) { let DocumentsPath = NSSearchPathForDirectoriesInDomains(FileManager.SearchPathDirectory.documentDirectory, FileManager.SearchPathDomainMask.userDomainMask, true).first! var databasePath = DocumentsPath + "/user_\(userId)" try! FileManager.default.createDirectory(at: URL(string: "file://" + databasePath)!, withIntermediateDirectories: true, attributes: nil) databasePath += "/database.sql3" let requireCreateTables = !(FileManager.default.fileExists(atPath: databasePath)) if sqlite3_open(databasePath, &db) == SQLITE_OK { if requireCreateTables { createContactTable() } } else { print("Open database at " + databasePath + " failed.") } } private func createContactTable() { //-- TODO }每次关上数据库时,将先查看指标数据库是否存在,不存在则进行创立。 ...

April 24, 2022 · 45 min · jiezi

关于im:InfoQ-公开课开放报名融云场景化低代码平台探究

(点击报名,直播地址将以短信发送 ) “人人都是开发者”是低代码平台的独特愿景。关注【融云寰球互联网通信云】理解更多 现实状态下,低代码平台容许开发者无需编码或只需编写大量代码,通过利落拽的形式,就能够可视化地疾速生成应用程序。 在数字化转型浪潮下,低代码被认为是解决企业开发人力不足、开发能力无限等问题的无效计划。 具体到通信垂直畛域,不同于传统的流程驱动型、表单驱动型、模型驱动型、BI 剖析类型平台,基于 IM + RTC 双核心能力打造的娱乐社交场景利用,开发者面对学习老本高、学习曲线平缓等难题,传统低代码平台的机制无奈高效适配。 因而,融云专门推出场景化低代码平台,打通融云根底服务能力,疾速接入通用能力,无缝对接、稳固开源。 融云场景化低代码平台特点买通根底能力,疾速接入简单业务模型配置化无缝对接,稳固开源4 月 19 日 20:00-21:00,融云场景化研发经理邵帅将在 InfoQ 公开课中带来《融云场景化低代码平台探索》主题分享。

April 19, 2022 · 1 min · jiezi

关于im:融云-IM-RTC-重磅优惠上线15-天免费体验1-年服务买一赠一

3 月马上过半,眼看着 Q1 就要过来了。开发者敌人们,你的我的项目停顿还顺利吗?关注【融云寰球互联网通信云】理解更多 在凡利用皆社交,通信能力成为 APP 必备模块的当初,通信服务选型大略是开发者必经节点。 如果你正因选型犯难,在性能完整性和服务响应度上难以抉择,在技术实力和价格优势间左右为难,或因无奈在生产环境做深度试用而担心产品的扩展性和稳定性。 融云重磅推出的“新星打算”堪称恰到好处,诸多难题一举破解! 即日起至 2022 年 4 月 30 日止,两大限时优惠不容错过 —— IM 商用版和 RTC 新客有礼:首次推出零门槛试用 15 天流动;1 年 IM 商用版专享礼:直降 2700 元,同时赠送 1 年 RTC 或推送 Plus。IM + RTC,15 天零门槛试用IM商用版15天收费 15 天内不限日活 / 畅享 IM 商用版全功能 / 仅限未开明 IM 商用版的新利用 创立注册账号数、日活不限残缺的 IM 即时通讯性能聊天室、群组数无限度收费赠送五大高级性能RTC音视频1万分钟收费 生产环境可用 / 视频不限分辨率 / 仅限未开明 RTC 的新利用 不限音视频、不限分辨率视频最高分辨率可反对 2K+不同分辨率耗费分钟数统一IM + RTC 的应用场景融云在 IM + RTC + X “全”通信解决方案根底上,行业首推第三代场景化 SDK,残缺封装底层能力和业务逻辑,反对开发者疾速上线音视频通话、语聊房、直播模块,开箱即用,贴近市场。 流动规定 ...

March 15, 2022 · 1 min · jiezi

关于im:超级群群组聊天室IM-产品的场景化特异功能

对方正在输出…关注【融云寰球互联网通信云】理解更多 当你跟敌人聊天时,对话框上显示这个状态,你的情绪是否充斥期待?这个由 MSN 独创的“聊天提醒器”性能,在这款产品成为历史后,被大多数社交软件保留了下来。 晋升交互体验始终是社交产品进化的次要命题,“聊天提醒器”让即时通讯肯定水平“实时”起来,是经典性能点设计之一。(为什么你的好友始终正在输出) 随着网络和通信技术的倒退,以 IM 即时通讯零碎为根底打造的社交软件性能越来越丰盛,包含对实时音视频通信技术的排汇。两大通信底层能力交融,成为社交 APP 的标配。 但即时通讯自身依然领有不可代替的应用场景 公众场合上,它让咱们释怀地进行私密沟通而不怕被“偷听”。职场社交中,即时通讯的文字表白人造要求更多的思考和条理性附加值。婚恋交友中,信息秒回,逐条回复事事有回应,始终是证实“在乎”水平的规范。年轻人群体中,即时通讯中应用缩略词和表情包更成为了一种必不可少的社交货币。尽管支流社交产品大多曾经是生态型产品,但其外围性能还是 IM。还有一些并非以 IM 零碎为外围的游戏、娱乐、生存服务类利用,IM 也是其重要的功能模块。 能够说,对带有社交属性的利用来说,IM 性能是必不可少的。 在 IM 这个外围通信能力上,融云有着传统劣势。艾瑞征询 Usertracker 多平台网民行为监测数据库显示:2021 年融云市场份额高达 70%,在月独立设施数居 TOP1000 的头部 APP 中,融云 IM 笼罩的 APP 日活设施数加总(非去重)超过 9000 万台。 这曾经是融云间断七年放弃 IM 市场占有率第一的领先地位。 (融云继续领跑IM市场) 同时,在经典的单 / 群聊、聊天室、零碎告诉之外,融云一直进行着产品的翻新迭代,近期推出的超级群产品在行业备受关注。 在 IM 即时通讯服务中—— 都以“群”为名,超级群和群组有何异同? 同样承载无下限用户,超级群和聊天室又各凭借什么产品差别而服务不同场景? 超级群 VS 群聊,此“群”非彼“群”超级群和群聊,这两个服务的名字中都带有“群”字,但产品状态却大不相同。 一般群组默认反对 3000 人的用户下限,而超级群成员数上不封顶。仅围绕这一外围差别点,二者便在存储、散发等方面有实质不同。 同时,在产品状态上,超级群独有频道创立性能,不便有独特特质的用户基于兴趣爱好等标签聚拢,并逐步造成丰盛多元的内容生态。 超级群 VS 聊天室,用户无下限,场景大不同聊天室和超级群都承载有限用户,但二者面对齐全不同的场景挑战。 聊天室是视频直播和语聊房的必备组件,用户基于某一主播或内容随机相遇,属于“萍水相逢”的关系,聚散随缘。 而超级群是以特定标签为根底吸引用户,在产品设计上也提供多种沟通形式以及推送告诉等多样服务,便于积淀长期关系,用户的社交关系属性更加“有来有往”。 从内容上来说,聊天室用户公布的内容更具即时性以及重复性,而超级群用户更偏向于就某一个话题一直空虚和欠缺内容,长期积淀为凋敝社区。 这也是超级群成为构建多元内容社区最佳抉择的起因之一。 IM 即时通讯作为社交利用必备能力,为解决不同的业务场景需要,衍生出了不同的产品类型。 在社交产品花样繁多、玩法翻新的当下,融云 IM 即时通讯不仅领有弱小的历史积攒劣势,同时在新社交状态频出的当下仍然引流行业,永葆创新力和生命力。

March 8, 2022 · 1 min · jiezi

关于im:即时通讯IM开源项目OpenIM重构版本发布-v200

介绍 OpenIM开发团队破费了2个月工夫,加班加点对代码进行了部分重构,优化代码构造,标准代码开发流程,为社区将来深度参加开发打好根底。因为改变较大,波及大量的测试工作,并且还有打包 公布 等一些琐碎的事件,导致公布延期了十天,在此略表歉意。后续会建设绝对残缺的开发和公布打算,也邀请各位社区同学参加OpenIM的建设工作。有志于参加OpenIM建设的同学,能够与我私聊,介绍零碎架构,并探讨社区开发流程和标准。 因为波及到数据库字段变动,下载前要先删除app把历史数据全副清理洁净 web端体验地址: http://121.37.25.71:23232/ pc端下载: https://pan.baidu.com/s/16MW3... 明码: jd15 安卓下载: https://www.pgyer.com/OpenIM iOS下载:审核中 稍后更新 新版本有哪些更新 客户端SDK架构重构 WsConn: ws连贯管理器。提供函数供其余方调用,具体包含: (1)ws连贯服务端,和OpenIM服务端放弃长连贯; (2)敞开ws连贯; (3)通过ws发送申请; WsRespAsyn: ws申请-响应同步器,因为ws是异步解决,须要把申请和响应关联起来,提供函数供其余方调用(音讯发送,心跳发送,拉取历史音讯等) (1)getCh:为每个申请生成一个channel和msgIncr,应用map关联起来 msgIncr->channel (2)notifyResp:对于ws收到的每个响应,通过msgIncr找到channel,并往channel发送响应,告诉响应达到; Ws: 模块对WsConn 和 WsRespAsyn性能进行整合(1)申请响应同步化,提供函数SendReqWaitResp,调用者通过ws发送申请后,期待此申请的响应达到。(2)对于接管到的推送音讯,把音讯写入PushMsgAndMaxSeqCh channel,触发MsgSync音讯同步协程。 具体实现:ReadData协程:接管服务端ws数据,并依据收到的数据类型(心跳、推送、踢出登录、拉取历史音讯等),触发不同的逻辑解决,(1)对于被动发送申请的响应,则调用WsRespAsyn的notifyResp响应触发接口;(2)对于push音讯,写入PushMsgAndMaxSeqCh ,触发MsgSync音讯同步协程。 MsgSync: 音讯同步器;蕴含Ws 和conversationCh 、 PushMsgAndMaxSeqCh ,启动音讯同步协程,对PushMsgAndMaxSeqCh 中的读取的数据做解决,具体包含: (1)从PushMsgAndMaxSeqCh 读取服务端最大seq:SvrMaxSeq(由heartbeat写入的),比照本地最大seq:LocalMaxSeq和服务端最大seq: SvrMaxSeq,计算出缺失的seq,从服务器拉取历史音讯,放入conversationCh ,触发conversation协程解决; (2)从PushMsgAndMaxSeqCh 读取ws推送音讯(由Ws的ReadData写入的推送音讯),如果音讯中的seq+1==LocalMaxSeq,则写入conversationCh,触发conversation解决,否则从服务端拉取音讯补齐[LocalMaxSeq+1, seq],放入conversationCh ,触发conversation协程解决; heartbeat: 心跳管理器,包含MsgSync (1)心跳协程,从服务端定时获取最大seq:SvrMaxSeq,而后把SvrMaxSeq让入PushMsgAndMaxSeqCh ,触发MsgSync音讯同步协程。 治理后盾第一版公布 治理后盾第一版体验地址: http://121.37.25.71:22331/#/l... 账号openIM123456 明码openIM1 db字段调整 好友申请表老版本 好友申请表新版本 以好友申请表为例,(1)对立并规范字段命名;(2)减少更多字段,能够实现更多的业务场景,同时减少扩大字段。 同样其余表都全副进行了标准:用户表,好友关系表,,群组表,群成员表,群申请表,黑名单表等 告诉机制欠缺 告诉机制欠缺,能够实现多端同步,实时更新本端以及其余端的本地db。比方挪动端设置好友备注,会实时同步到pc端,同样pc端设置完好友备注,会实时同步到挪动端,并更新本地db。具体实时同步告诉包含:从用户材料批改,到关系链建设,到群组的全方位告诉机制。 //////////////////////////////////////////NotificationBegin = 1000FriendNotificationBegin = 1200 ...

March 4, 2022 · 1 min · jiezi

关于im:即时通讯IM开源项目OpenIM本周版本发布-v107web端一键部署

介绍OpenIM:由前微信技术专家打造的基于 Go 实现的即时通讯(IM)开源我的项目,包含IM服务端和客户端SDK。开发者私有化部署,基于SDK二次开发,能够轻松代替第三方IM云服务,打造具备聊天、社交性能的app。无论是开发同城交友、企业办公亦或是当今最热门的元宇宙,还是在利用中集成IM性能,都十分便捷。OpenIM代码100%开源,开源协定Apache-2.0 License任何企业和集体都能够收费应用(包含商用)。 请各位看官多多反对,转发和宣传,助力OpenIM成为开源IM的No1 web端体验地址http://121.37.25.71:23232/ 我的项目成绩 截止到明天,github star数量达到6k,开源IM我的项目的领跑者 开发者文档:https://doc.rentsoft.cn/github地址:https://github.com/OpenIMSDK/...OpenIM不是集体兼职我的项目, 是商业化全职团队运作,有针对性VIP客户的免费服务,保障我的项目长期衰弱倒退。 本周重点个性客户端SDK v1.0.7个性类别pc web demo第二版公布,多端同步,群组功能完善新个性反对免打搅性能:设置接管音讯不揭示;设置不接管音讯新个性修复bug:同一个手机反复登录和踢出bug修复服务端 v1.0.6个性类别反对免打搅性能:设置接管音讯不揭示;设置不接管音讯新个性反对iOS推送新个性docker已更新,请拉取最新镜像,docker部署常见问题总结剖析和解决办法 见文档: https://doc.rentsoft.cn/demo/... OpenIM每周都会迭代公布新版本,次要针对bug修复和系统优化,特地值得注意的是,版本号的第一位数字代表大版本,个别是做了协定革新降级,服务器和客户端两者必须放弃大版本统一。 分支阐明:(1)dev:内部开发者在此分支上提交pr; (2)tuoyun:OpenIM外部专用;(3)main:最新可用分支; 服务端一键部署docker 装置、启动装置curl -sSL https://get.daocloud.io/docker | sh或者 curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun启动、进行重启docker服务 sudo service docker restart敞开docker sudo service docker stopdocker-compose装置sudo curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-composechmod +x /usr/local/bin/docker-compose部署如果确定是首次装置,能够间接采纳如下命令实现1-4步 git clone https://github.com/OpenIMSDK/Open-IM-Server.git --recursive; cd Open-IM-Server/script ; chmod +x *.sh ; ./env_check.sh;cd .. ; docker-compose up -d;cd script ; ./docker_check_service.sh ...

December 10, 2021 · 1 min · jiezi

关于im:分享一套golang实现的-IM-系统一键部署服务端客户端SDK全平台支持可以替代IM云服务

开篇自互联网诞生以来,即时通讯平台就始终存在。从世界范畴来看,WhatsApp、Facebook、 微信、Telegram是当先的音讯平台,用户次要应用这些平台与家人和敌人保持联系。随着互联网的倒退,人与人之间的沟通是刚需,无处不在,简直所有的APP都集成IM性能,从社交、游戏、到生存中的方方面面,打车、找房等。能够说IM作为一种通信能力,曾经成为互联网上的基础设施,成为许多APP不可或缺的性能。当初绝大多数APP应用IM云服务商的SDK,不便接入的同时,也带来了几个深层次的问题:(1)老本问题:企业每年额定领取上万乃至数十万的云服务费用,是个不小的老本;(2)数据隐衷问题:企业的用户数据、聊天记录等外围数据存储在IM云服务商,如何保证数据的安全性是个极大挑战;(3)需要定制问题:IM需要多样化,IM性能只能由IM云服务商通过SDK的模式提供给大家应用,对于一些定制化的需要,是否反对,什么时候实现,都是个未知数;(4)云服务商绑架问题:一旦应用IM云服务,造成捆绑关系,迁徙老本高,受制于人。 OpenIM采纳和IM云服务雷同的接口,提供服务端和客户端SDK,让开发者以收费或低成本接入IMSDK,并私有化部署,实现IM性能接入。 介绍OpenIM:由前微信技术专家打造的基于 Go 实现的即时通讯(IM)我的项目,从服务端到客户端SDK开源即时通讯(IM)整体解决方案。开发文档欠缺,代码100%开源,反对Andorid、iOS原生开发,反对Flutter、uni-app跨端开发,反对小程序、React等所有支流web前端技术框架, PC反对Electron,能够轻松代替第三方IM云服务。 后盾架构 服务端由接入层、逻辑层和存储层组成,益处在于各个档次可能根据业务特点专一于本人的事件,进步零碎复用性,升高业务间的耦合。 (1)接入层:音讯通过 websocket 协定接入,其余通过 http/https 协定接入,音讯是高频及外围性能,通过双协定路由,体现了轻重拆散的设计思维。 (2)逻辑层:通过 rpc 实现无状态逻辑服务,易于平行扩大,音讯通过 MQ 解耦。 (3)存储层:redis 存储 token 和 seq;mongodb 存储离线音讯,并定时删除 14 天(可自行配置)前数据;mysql 存储全量历史音讯以及用户相干材料。数据分层存储,充分利用不同存储组件的个性。 (4)Etcd:服务注册和发现、以及分布式配置核心。 音讯流程 Open-IM 音讯模型采纳经典的收件箱模型,并通过全局 seq 做音讯对齐,这里带来架构的简化,体现了简略美的架构设计理念。很多开发者通过网络文章,理解到收件箱模型的原理,也晓得 seq 的概念,但如何在我的项目中做衡量和取舍,爱因斯坦已经说过“事件应该力求简略,不过不能过于简略”,咱们看到很多技术文章对收件箱模型和 seq 的滥用,要么零碎设计简单,要么过于简略,最初的后果是零碎不稳固,音讯可达率无奈达到要求。以下咱们简略解说音讯如何发送,零碎如何简略解耦,接管方如何实时收到音讯,并如何利用 seq 做全局音讯对齐,确保音讯百分百可达。 客户端架构 客户端 SDK 负责和 IM 服务端交互,本地数据存储和同步,音讯、事件回调。开发者通过集成 SDK,自行开发聊天界面 UI,设置事件监听回调实现数据和 UI 对接。 Open-IMSDK 分为三层:网络层、逻辑层、存储层。分层治理,各司其职,实现高效、稳固、对立的客户端架构。 SDK集成流程 OpenIM SDK 集成非常简单,因为开发者私有化部署,代码、配置、数据都在自家服务器上,不必向云平台申请 AppKey 和 Secret,相比第三方 IM 云服务,可见 OpenIM 更平安、可控、自由度更高。 地址官网文档地址: https://doc.rentsoft.cn/ OpenIM github开源地址: https://github.com/OpenIMSDK/... OpenIM官网 :https://www.rentsoft.cn ...

October 8, 2021 · 1 min · jiezi

关于im:IM开源推荐前微信技术专家打造golang实现一键部署客户端SDK全平台支持轻松替代IM云服务

背景OpenIM成立之初就将“开源”作为外围策略来推动,开源充分体现了自在、平等、分享的互联网精力。 寰球范畴频繁产生的数据泄露、勒索病毒、隐衷滥用等安全事件一次次给企业敲响警钟,企业管理者对数据资产的价值、数据安全的重要性有了更清晰的意识,数据安全成就企业外围价值。 IM作为外围业务数据,平安的重要性毋庸置疑,OpenIM开源以及私有化部署让企业能更放心使用。 现在IM云服务商免费高企,如何让企业低成本、平安、牢靠接入IM服务,是OpenIM的历史使命,也是咱们后退的方向。 劣势OpenIM:由前微信技术专家打造的基于 Go 实现的即时通讯(IM)我的项目,从服务端到客户端SDK开源即时通讯(IM)整体解决方案。开发文档欠缺,代码100%开源,反对Andorid、iOS原生开发,反对Flutter、uni-app跨端开发,反对小程序、React等所有支流web前端技术框架, PC反对Electron,能够轻松代替第三方IM云服务 OpenIM曾经具备IM和音视频实时通话的能力,提供SDK 接入和服务端私有化部署。 当初我的项目star增长迅速,短短几周内达到1k,微信群的开发者500人,社区开发者30人。 OpenIM诚邀现诚邀寰球技术极客退出开源社区奉献代码,充分发扬自在、平等、分享的互联网精力,独特打造寰球开源IM的第一社区。 官网文档: https://doc.rentsoft.cn/ github地址: https://github.com/OpenIMSDK/... 欢送大家奉献Star和Fork ,转发并邀请开发者进群,打造开源IM的No1 为什么要开源尽管开源工作可能会产生无益的后果,但它不是慈悲行为。将工作公布为凋谢源代码和相应的奉献过程最终会比其余关闭源代码过程带来更高的初始投资回报。约翰·纳什是驰名数学家,也是奥斯卡获奖电影《漂亮的心灵》的配角,他因在“单干博弈”方面的工作而取得诺贝尔经济学奖。他证实了单干不是零和博弈,通过单干,所有参与者可能会产生比他们的投资更高的回报。事实世界中最好的例子可能是开源软件。对于OpenIM来说,次要解决两类需要,第一对于老本敏感的初创企业,每年几万的IM云服务费用是个不小的开销,而应用OpenIM能够零老本进行代替;第二对于信息安全比拟敏感的企业,比方航天、政务等,如果应用私有云IM服务,企业外部的敏感信息可能存在泄露的危险,可能会给企业带来灭顶之灾。 后盾架构 服务端由接入层、逻辑层和存储层组成,益处在于各个档次可能根据业务特点专一于本人的事件,进步零碎复用性,升高业务间的耦合。 (1)接入层:音讯通过 websocket 协定接入,其余通过 http/https 协定接入,音讯是高频及外围性能,通过双协定路由,体现了轻重拆散的设计思维。 (2)逻辑层:通过 rpc 实现无状态逻辑服务,易于平行扩大,音讯通过 MQ 解耦。 (3)存储层:redis 存储 token 和 seq;mongodb 存储离线音讯,并定时删除 14 天(可自行配置)前数据;mysql 存储全量历史音讯以及用户相干材料。数据分层存储,充分利用不同存储组件的个性。 (4)Etcd:服务注册和发现、以及分布式配置核心。 音讯流程 Open-IM 音讯模型采纳经典的收件箱模型,并通过全局 seq 做音讯对齐,这里带来架构的简化,体现了简略美的架构设计理念。很多开发者通过网络文章,理解到收件箱模型的原理,也晓得 seq 的概念,但如何在我的项目中做衡量和取舍,爱因斯坦已经说过“事件应该力求简略,不过不能过于简略”,咱们看到很多技术文章对收件箱模型和 seq 的滥用,要么零碎设计简单,要么过于简略,最初的后果是零碎不稳固,音讯可达率无奈达到要求。以下咱们简略解说音讯如何发送,零碎如何简略解耦,接管方如何实时收到音讯,并如何利用 seq 做全局音讯对齐,确保音讯百分百可达。 客户端架构 客户端 SDK 负责和 IM 服务端交互,本地数据存储和同步,音讯、事件回调。开发者通过集成 SDK,自行开发聊天界面 UI,设置事件监听回调实现数据和 UI 对接。OpenIMSDK 分为三层:网络层、逻辑层、存储层。分层治理,各司其职,实现高效、稳固、对立的客户端架构。通过golang实现,全终端笼罩。 OpenIM服务端一键部署 OpenIM集成流程 OpenIM SDK 集成非常简单,因为开发者私有化部署,代码、配置、数据都在自家服务器上,不必向云平台申请 AppKey 和 Secret,相比第三方 IM 云服务,可见 OpenIM 更平安、可控、自由度更高。 ...

October 8, 2021 · 1 min · jiezi

关于im:OpenIM原创AppServerAppClientOpenIMServer以及OpenIMSDK之间的关系

写在后面Open-IM是由前微信技术专家打造的开源的即时通讯组件。Open-IM包含IM服务端和客户端SDK,实现了高性能、轻量级、易扩大等重要个性。开发者通过集成Open-IM组件,并私有化部署服务端,能够将即时通讯、实时网络能力疾速集成到本身利用中,并确保业务数据的安全性和私密性。 理解更多原创文章:【OpenIM原创】开源OpenIM:轻量、高效、实时、牢靠、低成本的音讯模型 【OpenIM原创】C/C++调用golang函数,golang回调C/C++函数 【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理 【OpenIM扩大】OpenIM服务发现和负载平衡golang插件:gRPC接入etcdv3 【开源OpenIM】高性能、可伸缩、易扩大的即时通讯架构 如果您有趣味能够在文章结尾理解到更多对于咱们的信息,期待着与您的交换单干。 上图示意 AppServer、AppClient、Open-IM Server以及Open-IM-SDK 之间的关系。 Open-IM即时通信提供了单聊、群聊、音讯推送、平安鉴权等根本的IM性能、服务器端提供业务回调接口,在音讯发送过程中回调用户的业务服务器,能够实现具体的业务性能,例如音讯过滤,屏蔽等性能。Open-IM提供IM全托管服务,包含用户材料、好友关系、群组、音讯、推送等性能。业务服务端只须要在用户注册、时调用Open-IMserver提供的获取token的接口,返回后,由app保留在本地,在下次登录时候携带token进行平安校验。客户端集成Open-IMSDK,仅仅须要调用初始化、加载会话等几个接口,无需更改原有App的架构,即能够实现带UI的IM全托管。如果用户须要深度定制化开发,能够依据咱们提供的OpenIM Client SDK接口,自定义开发,Open-IM客户端SDK是依据具体的罕用的IM业务形象而成,为了不便用户调用,咱们尽力使其简洁、高效,而且易于扩大,不便用户可能依据本人的业务需要自定义音讯。2. Open-IM用户注册 app注册新用户时,your-app-server实现与本身逻辑相干的验证后,生成uid;app-server 会携带 secret, platform, uid 等信息调用/auth/user_register接口实现open-im新用户注册;open-im-server测验信息后,给your-app-server返回胜利,your-app-server给app返回胜利;对于app存量用户,间接批量调用/auth/user_register实现open-im新用户注册;对于/auth/user_register具体申请响应字段,请参考服务端API文档;3. Open-IM用户登录 用户登录app时,your-app-server先验证app账号密码,胜利后调用/auth/user_token获取uid+token;your-app-server给客户端返回:uid+token+其余app数据;客户端open-im-sdk带上uid+token登录open-im;对于/auth/user_token具体申请响应字段,请参考服务端API文档;OpenIM github开源地址: https://github.com/OpenIMSDK/... OpenIM官网 :https://www.rentsoft.cn OpenIM官方论坛:https://forum.rentsoft.cn/ 咱们致力于通过开源模式,为寰球企业/开发者提供简略、易用、高效的IM服务和实时音视频通信能力,帮忙开发者升高我的项目的开发成本,并让开发者掌控业务的外围数据。 IM作为外围业务数据,平安的重要性毋庸置疑,OpenIM开源以及私有化部署让企业能更放心使用。 现在IM云服务商免费高企,如何让企业低成本、平安、牢靠接入IM服务,是OpenIM的历史使命,也是咱们后退的方向。 如您有技术下面的浅见请到咱们的论坛分割沟通,用户也可与咱们的技术人员谈讨应用方面的难题以及见解

September 23, 2021 · 1 min · jiezi

关于im:OpenIM原创uniapp使用之-初始化会话-消息-好友-监听器

写在后面Open-IM是由前微信技术专家打造的开源的即时通讯组件。Open-IM包含IM服务端和客户端SDK,实现了高性能、轻量级、易扩大等重要个性。开发者通过集成Open-IM组件,并私有化部署服务端,能够将即时通讯、实时网络能力疾速集成到本身利用中,并确保业务数据的安全性和私密性。 理解更多原创文章:【OpenIM原创】开源OpenIM:轻量、高效、实时、牢靠、低成本的音讯模型 【OpenIM原创】C/C++调用golang函数,golang回调C/C++函数 【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理 【OpenIM扩大】OpenIM服务发现和负载平衡golang插件:gRPC接入etcdv3 【开源OpenIM】高性能、可伸缩、易扩大的即时通讯架构 如果您有趣味能够在文章结尾理解到更多对于咱们的信息,期待着与您的交换单干。在初始化SDK前须要先初始化局部全局监听器,初始化胜利后可在适合的机会通过globalEvent对相干回调进行监听。 // 会话监听this.$openSdk.setConversationListener();// 音讯状态监听this.$openSdk.addAdvancedMsgListener();// 群组监听this.$openSdk.setGroupListener()// 好友监听this.$openSdk.setFriendListener();会话监听回调列表event阐明onConversationChanged会话列表扭转onNewConversation新会话onSyncServerFailed-onSyncServerFinish-onSyncServerStart-onTotalUnreadMessageCountChanged音讯未读总数扭转音讯状态监听回调列表event阐明onRecvNewMessage接管到新音讯onRecvMessageRevoked其余用户撤回告诉onRecvC2CReadReceipt对方实时已读告诉群组监听回调列表event阐明onApplicationProcessed入群申请被解决onGroupCreated群组创立onGroupInfoChanged群组信息扭转onMemberEnter新成员退出群组onMemberInvited邀请成员退出onMemberKicked踢出成员onMemberLeave成员退群onReceiveJoinApplication收到入群申请好友监听回调列表event阐明onBlackListAdd增加黑名单onBlackListDeleted移除黑名单onFriendApplicationListAccept承受好友申请onFriendApplicationListAdded好友申请列表减少onFriendApplicationListDeleted好友申请列表缩小onFriendApplicationListReject回绝好友申请onFriendInfoChanged好友信息更新onFriendListAdded好友列表减少onFriendListDeleted好友列表缩小2. 初始化OpenIMSDKconst config = { platform: 1, //平台类型 ipApi: "http://1.14.194.38:10000", //api域名地址 ipWs: "ws://1.14.194.38:17778", //websocket地址 /** * ps:上述配置适宜于通过ip拜访 若通过域名且配置了https证书请应用如下配置形式 * ipApi: "https://open-im.rentsoft.cn", * ipWs: "wss://open-im.rentsoft.cn/wss", */ dbDir, //SDK数据寄存目录}//返回值为布尔值告知是否初始化胜利this.flag = this.$openSdk.initSDK(config);dbDir为SDK初始化目录绝对路径,可通过H5+API获取 plus.io.requestFileSystem(plus.io.PRIVATE_DOC, function(fs) { fs.root.getDirectory( "user", { create: true, }, (entry) => { //初始化SDK ... }, (error) => { console.log(error); } );});初始化SDK胜利后会设置一个网络连接状态的回调监听,但回调在调用登录之后才会进行返回。初始化监听回调事件event阐明initStatus初始化状态onConnectFailed连贯失败onConnectSuccess连贯胜利onConnecting连贯中onKickedOffline被踢下线onSelfInfoUpdated批改个人信息onUserTokenExpired账号token过期OpenIM github开源地址: https://github.com/OpenIMSDK/... OpenIM官网 :https://www.rentsoft.cn OpenIM官方论坛:https://forum.rentsoft.cn/ 咱们致力于通过开源模式,为寰球企业/开发者提供简略、易用、高效的IM服务和实时音视频通信能力,帮忙开发者升高我的项目的开发成本,并让开发者掌控业务的外围数据。 IM作为外围业务数据,平安的重要性毋庸置疑,OpenIM开源以及私有化部署让企业能更放心使用。 ...

September 22, 2021 · 1 min · jiezi

关于im:即时通讯系统架构设计如何设计一款WhatsApp

本文译自tech takshila经OpenIM技术人员整顿订正后公布。写在后面Open-IM是由前微信技术专家打造的开源的即时通讯组件。Open-IM包含IM服务端和客户端SDK,实现了高性能、轻量级、易扩大等重要个性。开发者通过集成Open-IM组件,并私有化部署服务端,能够将即时通讯、实时网络能力疾速集成到本身利用中,并确保业务数据的安全性和私密性。 理解更多原创文章:【OpenIM原创】开源OpenIM:轻量、高效、实时、牢靠、低成本的音讯模型 【OpenIM原创】C/C++调用golang函数,golang回调C/C++函数 【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理 【OpenIM扩大】OpenIM服务发现和负载平衡golang插件:gRPC接入etcdv3 【开源OpenIM】高性能、可伸缩、易扩大的即时通讯架构 如果您有趣味能够在文章结尾理解到更多对于咱们的信息,期待着与您的交换单干。免责申明:这是设计WhatsApp等即时通讯零碎的一种办法。然而,咱们不能保障WhatsApp是以这种形式设计的。这是咱们设计相似零碎的想法。 问题陈说设计一个即时通讯平台,如WhatsApp或Signal,用户能够利用该平台互相发送音讯。应用程序的一个重要方面是聊天信息不会永恒存储在应用程序中。 乏味的事实:一些聊天信使(如FB Messenger)存储聊天信息,除非用户明确删除它。然而,像WhatsApp这样的即时通讯工具不会将音讯永恒保留在服务器上。 零碎需要instant messenger应用程序应满足以下要求。 它应该可能反对用户之间的一对一对话。它应该可能向其余用户显示发送/交付/读取确认。它应该可能提供对于用户上次流动工夫的信息。它应该容许用户共享图像。它应该可能向其余用户发送推送告诉。容量布局咱们须要建设一个高度可扩大的平台,可能反对WhatsApp规模的流量。此外,在进行容量布局时,咱们须要确保思考顶峰流量的最坏状况。上面列出了咱们能够用来估算应用程序容量的一些数字(如WhatsApp)。 -每月应用程序上的用户数:10亿 -顶峰流量时每秒的流动用户数:650000 -顶峰流量时每秒的邮件数:4000万 整个应用程序将由几个微服务组成,每个微服务执行特定的工作。解决聊天信息流量的数据立体(网站管理员包含到分布式系统章节的链接)(咱们称之为chat microservice)中所需的服务器数量能够应用以下等式进行预计。 # ℎ = (#聊天信息/秒)__∗ 提早)/#每台服务器的并发连贯 假如每台服务器的并发连接数为100K,发送音讯的提早为20毫秒。在这种状况下,聊天服务器机队中所需的服务器的预计数量(应用上述等式)将为8(即4000万*20毫秒/100K)。在规范实际中,倡议再增加几个服务器,以解决这些服务器可能的故障。在接下来的一节中,咱们将看到这些聊天服务器对总体基础设施老本的影响。 乏味的事实:在本次演讲中,Rick Reed(软件工程师@WhatsApp)谈到了优化基于Erlang的服务器应用程序,以及调整FreeBSD内核以反对每台服务器数百万个并发连贯。这在很大水平上帮忙了他们放弃尽可能小的服务器占用空间。 高级设计此即时通讯应用程序所需的性能能够应用两种微服务建模:聊天服务和长期服务。聊天服务将为沉闷用户发送的在线聊天信息流量提供服务。该服务将查看接管音讯的用户是否在线。如果用户在线,则音讯将立刻转发给该用户。否则,音讯将由长期服务解决。此服务将负责保护发送给脱机用户的所有音讯(文本或图像)。数据将临时存储在长期存储器中,直到脱机用户复原联机。咱们将在前面的一节中提供无关各个组件的更多详细信息。 乏味的事实:WhatsApp实际上应用了一种十分相似的办法,正如同一位WhatsApp工程师(Rick Reed)在另一次演讲中所探讨的。 API设计咱们能够公开一个REST端点来与聊天服务交互。上面介绍了用于发送音讯的API端点的定义。 sendMessage(String fromUser、String toUser、ClientMetaData ClientMetaData、String message) 申请: _fromUser:\u发送申请的用户ID _toUser:\u向其发送申请的用户ID clientMetaData:用于存储客户端信息(如设施详细信息、地位等)的元数据。 音讯:作为通信的一部分发送的音讯。 数据模型咱们将存储详细信息,例如用户连贯到的服务器以及用户上次流动的工夫。咱们能够应用基于文档的数据库(如MongoDB)来存储用户信息,如用户的最初流动工夫(也称为心跳工夫)。数据模型将相似于下表。 用户ID(香港)心跳工夫已连贯服务器 表1:数据模型-用户信息 组件图在本节中,咱们将探讨在一对一通信中发送音讯的两种不同场景。之后,咱们将探讨须要反对的其余性能,例如推送告诉和用户活动状态。最初,咱们将钻研进行优化和解决故障场景的不同机制。 一对一通信这里,咱们将探讨与向另一个用户发送音讯相干的两种不同场景。第一种状况波及向在线用户发送文本音讯。在第二个场景中,咱们形容了向脱机用户发送图像所波及的操作序列。 场景1:向在线用户发送文本 上面介绍了向在线用户发送文本音讯的序列图中每个步骤的详细信息。 步骤1:Alice向Bob发送一条音讯,该音讯被定向到Alice连贯的聊天服务器。步骤2:Alice从其连贯的聊天服务器(即聊天服务器A)取得确认,音讯标记为Alice端发送。步骤3:聊天服务器向数据存储器发出请求,以获取无关Bob连贯的聊天服务器的信息。步骤4:聊天室存储返回Bob连贯到聊天室服务器的信息。步骤5:聊天室服务器A将音讯转发给聊天室服务器B。步骤6:应用推送机制将消息传递给Bob。步骤7:Bob将ACK发送回聊天服务器。步骤8:ACK被转发到Alice连贯的聊天服务器A。步骤9:ACK被传递给Alice,并被标记为已传递。步骤10:当Bob浏览音讯时(假如15分钟后),另一个ACK被发送到Chat_Server_B。步骤11:聊天室服务器申请获取Alice连贯的服务器。步骤12:聊天室存储返回Alice连贯到聊天室服务器的信息。步骤13:聊天室服务器B将读取确认转发给聊天室服务器A。步骤14:将ACK转发给Alice,将申请标记为已读。场景2:向脱机用户发送媒体文件 上面介绍了序列图中向脱机用户发送图像的每个步骤的详细信息。 步骤1:Alice向Bob发送一个图像,该图像被转发到聊天服务器A,Alice与之连贯的服务器。步骤2:聊天服务器将图像上传到文件服务器,文件存储在目录构造中步骤3:文件服务器将上传文件的图像url返回给聊天室服务器。步骤4:图像url返回给Alice,用于在Alice的设施上出现图像。图像被标记为在Alice端发送。步骤5:聊天服务器向Bob连贯的服务器发出请求。步骤6:聊天室存储返回Bob离线的信息。步骤7:聊天服务器将蕴含图像url的音讯转发给长期服务器步骤8:长期服务器将蕴含图像url的音讯存储在长期存储器中。第九步:Bob上线并与Chat_Server_B进行心跳(网站管理员包含链接)。步骤10:聊天服务器从长期服务器获取Bob的长期音讯。步骤11:聊天服务器将长期音讯转发给Bob。步骤12:Bob从文件服务器获取图像。此时,映像将被传送到Bob的设施,所有对瞬态音讯的援用都将从零碎中删除。步骤13:Bob的设施向聊天服务器发送Alice图像的确认步骤14:获取Alice连贯到的服务器的信息;i、 e.聊天室服务器步骤15:将确认转发至聊天室服务器步骤16:将ACK传递给Alice,将音讯标记为已传递。瞬态数据存储咱们能够应用基于FIFO的策略实现基于队列的机制来存储和检索瞬态音讯。为此,咱们能够应用现有的基于云的技术,如AmazonSQS或WindowsAzure队列服务。咱们能够应用这些队列来存储发送给脱机用户的长期音讯。一旦消息传递给脱机用户,所有对这些长期音讯的援用都将从零碎中删除。 推送告诉应用推送技术向用户传递音讯有两种办法:客户端推送或服务器推送。如果咱们沿着客户机申请的路线走上来,咱们能够在长轮询和短轮询之间做出决定。另一方面,有两种办法能够实现服务器推送办法:WebSocket和服务器发送事件(SSE)。Websockets曾经成为聊天应用程序事实上的通信协议。咱们在上面的局部中提供了无关它的更多详细信息。 应用轮询技术,客户机定期向服务器申请新数据。抉择轮询技术的衡量决定能够应用上面提到的数据点。 短轮询:(例如,基于AJAX的计时器)长处:如果申请之间的工夫距离较长,则更简略且不太耗费服务器毛病:不适用于须要以最小提早告诉服务器事件的状况长轮询:(例如,基于XHR的Comet)长处:服务器事件的告诉不会提早毛病:更简单,耗费更多服务器资源将服务器音讯推送到客户端的办法次要有两种类型。第一种是WebSocket,它是一种通信协议。它通过单个TCP连贯提供双工通信信道。因为双向通信,它非常适合聊天应用程序等场景。另一种称为服务器发送事件(SSE),它容许服务器在建设初始客户机-服务器连贯后异步向客户机发送“新数据”。SSE更适宜发布者-订阅者模型,如实时流式股票价格;twitter提供更新和浏览器告诉。 用户活动状态用户最初一次处于活动状态是能够在即时消息中找到的规范性能。咱们在下面的表1中展现了存储相干信息的数据模型 在图4中,咱们展现了应用WebSocket在客户端和服务器之间保护连贯的机制。一旦在客户端和服务器之间建设了初始连贯,通信就会切换到双向二进制协定。客户端和服务器之间的连贯应用心跳放弃活动状态。咱们将上次从用户接管心跳的工夫存储在数据库中。而后能够查问数据存储以获取用户上次流动的工夫。 优化咱们能够应用上面列出的参数来倡议零碎中的优化。在本文中,咱们提供了倡议系统优化所应遵循的办法的详细信息。 提早:咱们能够应用分布式缓存(包含指向分布式缓存的链接),例如Redis,在内存中缓存用户活动状态及其最近聊天的信息。这可能有助于缩小应用程序的总体提早,并提供更好的客户体验。甚至一些数据库解决方案也提供了内存缓存解决方案,如Amazon DynamoDB Accelerator。基础设施老本:从零碎中能够显著看出,聊天服务器对基础设施老本的重要奉献。如果不管制聊天服务器的脚印,那么聊天服务器产生的老本可能会迅速减少。一种办法是减少每个主机的连接数。这将大大减少保护服务所需的服务器数量。咱们能够通过调整服务器配置和抉择适合的技术来实现这项工作。例如,WhatsApp的工程师通过优化基于Erlang的服务器应用程序和调优FreeBSD内核,可能在每台主机上实现数百万个连贯可用性:咱们能够保护长期音讯的多个正本,这样即便其中一个正本中的音讯失落,也能够从另一个正本中检索。这意味着要保护这些长期音讯的正本。客户端将负责从两个队列获取音讯,并将它们合并。咱们将在下一节中探讨更多内容。解决瓶颈 零碎中更容易产生故障的次要瓶颈是聊天服务器和长期存储解决方案。在上面的局部中,咱们举荐了一些解决此类故障的办法。 聊天服务器故障:零碎中的聊天服务器将放弃与用户的连贯。有两种解决聊天服务器故障的办法。一种办法是将这些TCP连贯传输到另一台服务器;然而,这种故障转移的实现并非微不足道。第二个绝对简略的办法是让用户客户端在连贯失落的状况下主动启动连贯。用户连贯到的服务器的信息须要在数据库中更新,这与咱们采取的办法无关。例如,在图5中,咱们展现了解决此故障场景的示例。咱们能够看到User1连贯到Server1,当该服务器敞开时,将从新建设与另一台服务器(即Server2)的连贯,并在数据库中更新此信息。 瞬态存储故障:瞬态存储是另一个容易产生故障的组件,可能会导致脱机用户在传输过程中失落音讯。咱们能够复制每个用户的长期存储,以避免在他们脱机时发送给他们的音讯失落。当用户从新联机时,将查问并合并用户长期存储的原始实例和正本实例。在图6中,咱们展现了一种解决刹时存储故障的机制,该故障在用户从新联机时启动。 ...

September 18, 2021 · 1 min · jiezi

关于im:OpenIM原创uniapp使用之-初始化OpenIM-SDK

写在后面Open-IM是由前微信技术专家打造的开源的即时通讯组件。Open-IM包含IM服务端和客户端SDK,实现了高性能、轻量级、易扩大等重要个性。开发者通过集成Open-IM组件,并私有化部署服务端,能够将即时通讯、实时网络能力疾速集成到本身利用中,并确保业务数据的安全性和私密性。 开创团队来自前微信高级架构师、IM/WebRTC专家团队,咱们致力于用开源技术发明服务价值,打造轻量级、高可用的IM架构,开发者只需简略调用 SDK,即可在利用内构建多种即时通讯及实时音视频互动场景。 IM作为外围业务数据,平安的重要性毋庸置疑,OpenIM开源以及私有化部署让企业能更放心使用。 现在IM云服务商免费高企,如何让企业低成本、平安、牢靠接入IM服务,是OpenIM的历史使命,也是咱们后退的方向。 理解更多原创文章:【OpenIM原创】开源OpenIM:轻量、高效、实时、牢靠、低成本的音讯模型 【OpenIM原创】C/C++调用golang函数,golang回调C/C++函数 【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理 【OpenIM扩大】OpenIM服务发现和负载平衡golang插件:gRPC接入etcdv3 【开源OpenIM】高性能、可伸缩、易扩大的即时通讯架构 如果您有趣味能够在文章结尾理解到更多对于咱们的信息,期待着与您的交换单干。初始化SDK的listener(OnInitSDKListener)回调是在调用login办法后才开始进行。 // Initialize SDK OpenIM.iMManager ..initSDK( platform: Platform.isAndroid ? IMPlatform.android : IMPlatform.ios, ipApi: '', ipWs: '', dbPath: '', listener: OnInitSDKListener( onConnecting: () {}, onConnectFailed: (code, error) {}, onConnectSuccess: () {}, onKickedOffline: () {}, onUserSigExpired: () {}, onSelfInfoUpdated: (user) {}, ), ) // Add message listener (remove when not in use) ..messageManager.addAdvancedMsgListener(OnAdvancedMsgListener( onRecvMessageRevoked: (msgId) {}, onRecvC2CReadReceipt: (list) {}, onRecvNewMessage: (msg) {}, )) // Set up message sending progress listener ..messageManager.setMsgSendProgressListener(OnMsgSendProgressListener( onProgress: (msgId, progress) {}, )) // Set up friend relationship listener ..friendshipManager.setFriendshipListener(OnFriendshipListener( onBlackListAdd: (u) {}, onBlackListDeleted: (u) {}, onFriendApplicationListAccept: (u) {}, onFriendApplicationListAdded: (u) {}, onFriendApplicationListDeleted: (u) {}, onFriendApplicationListReject: (u) {}, onFriendInfoChanged: (u) {}, onFriendListAdded: (u) {}, onFriendListDeleted: (u) {}, )) // Set up conversation listener ..conversationManager.setConversationListener(OnConversationListener( onConversationChanged: (list) {}, onNewConversation: (list) {}, onTotalUnreadMessageCountChanged: (count) {}, onSyncServerFailed: () {}, onSyncServerFinish: () {}, onSyncServerStart: () {}, )) // Set up group listener ..groupManager.setGroupListener(OnGroupListener( onApplicationProcessed: (groupId, opUser, agreeOrReject, opReason) {}, onGroupCreated: (groupId) {}, onGroupInfoChanged: (groupId, info) {}, onMemberEnter: (groupId, list) {}, onMemberInvited: (groupId, opUser, list) {}, onMemberKicked: (groupId, opUser, list) {}, onMemberLeave: (groupId, info) {}, onReceiveJoinApplication: (groupId, info, opReason) {}, ));初始化监听回调事件event阐明onConnectFailed连贯失败onConnectSuccess连贯胜利onConnecting连贯中onKickedOffline被踢下线onSelfInfoUpdated批改个人信息onUserTokenExpired账号token过期会话监听回调列表event阐明onConversationChanged会话列表扭转onNewConversation新会话onSyncServerFailed-onSyncServerFinish-onSyncServerStart-onTotalUnreadMessageCountChanged音讯未读总数扭转音讯状态监听回调列表event阐明onRecvNewMessage接管到新音讯onRecvMessageRevoked其余用户撤回告诉onRecvC2CReadReceipt对方实时已读告诉群组监听回调列表event阐明onApplicationProcessed入群申请被解决onGroupCreated群组创立onGroupInfoChanged群组信息扭转onMemberEnter新成员退出群组onMemberInvited邀请成员退出onMemberKicked踢出成员onMemberLeave成员退群onReceiveJoinApplication收到入群申请好友监听回调列表event阐明onBlackListAdd增加黑名单onBlackListDeleted移除黑名单onFriendApplicationListAccept承受好友申请onFriendApplicationListAdded好友申请列表减少onFriendApplicationListDeleted好友申请列表缩小onFriendApplicationListReject回绝好友申请onFriendInfoChanged好友信息更新onFriendListAdded好友列表减少onFriendListDeleted好友列表缩小OpenIM github开源地址: ...

September 18, 2021 · 1 min · jiezi

关于im:IM开源推荐前微信技术专家打造的开源的即时通讯组件OpenIM

Open-IM是由前微信技术专家打造的开源的即时通讯组件。Open-IM包含IM服务端和客户端SDK,实现了高性能、轻量级、易扩大等重要个性。开发者通过集成Open-IM组件,并私有化部署服务端,能够将即时通讯、实时网络能力疾速集成到本身利用中,并确保业务数据的安全性和私密性。 Open-IM包含哪些模块(一)客户端(1) golang实现的跨平台的SDK:Open-IM-SDK-Core ,开发者不须要关怀 (2)在Open-IM-SDK-Core 根底上生成的iOS版本SDK:Open-IM-SDK-iOS ,供开发者援用 (3)在Open-IM-SDK-Core 根底上生成的Android版本SDK:Open-IM-SDK-Android,供开发者援用 (4)在Open-IM-SDK-iOS、Open-IM-SDK-Android生成的Flutter版本SDK:Open-IM-SDK-Flutter ,供开发者援用 (5)在Open-IM-SDK-iOS、Open-IM-SDK-Android生成的uni-app版本SDK:Open-IM-SDK-Uniapp,供开发者援用 (6)基于Open-IM-SDK-iOS开发的、供开发者参考的iOS Demo:Open-IM-iOS-Demo ,供开发者参考 (7)基于Open-IM-SDK-Android开发的Android Demo:Open-IM-Android-Demo ,供开发者参考 (8)基于Open-IM-SDK-Flutter开发的Flutter Demo:Open-IM-Flutter-Demo ,供开发者参考 (9)基于Open-IM-SDK-Uniapp开发的uni-app Demo:Open-IM-Uniapp-Demo,供开发者参考 (二)服务端(1)纯golang实现的服务端 Open-IM-Server (2)docker镜像:open-im-server (三)治理后盾蕴含统计报表、用户治理等经营管理系统:Open-IM-Admin(开发中) Open-IM有什么特色(1) 社区版开源永恒收费 社区版代码全副开源,永恒收费,包含客户端和服务端,由前微信技术专家打造,并邀请寰球技术极客参加建设。 (2) 易扩大 服务端采纳golang实现,独创“所有皆音讯”的通信模型,轻松实现自定义音讯和扩大性能。 (3) 业余技术服务 每个技术人员都承当技术客服的角色,强化社区,不提工单,及时解答。 (4) 高性能 借鉴并优化通信架构,形象在线音讯、离线音讯、历史音讯存储模型,分层治理架构,反对集群部署。 (5) 平安 社区版代码全副开源,服务端私有化部署,数据自我掌控。将来退出寰球最平安的signal端到端加密协议。 (6) 全平台反对 目前反对Andorid、 iOS、Flutter、Uniapp、Unity、Windows等支流终端平台,Flutter、iOS、Uniapp已有成熟demo能够体验。 开发者能够应用Open-IM代替市场上各种IM云服务,除了降低成本,还赋予开发者更多的灵活性和自主性。咱们通过开源的形式,邀请寰球技术极客来参加Open-IM建设,使每位开发者都能收费应用最优良的IM组件,让每个app都具备即时通讯能力。 市场现有产品的痛点自互联网诞生以来,即时通讯平台就始终存在。从世界范畴来看,WhatsApp、Facebook、 微信、Telegram是当先的音讯平台,用户次要应用这些平台与家人和敌人保持联系。随着互联网的倒退,人与人之间的沟通是刚需,无处不在,简直所有的APP都集成IM性能,从社交、游戏、到生存中的方方面面,打车、找房等。能够说IM作为一种通信能力,曾经成为互联网上的基础设施,成为许多APP不可或缺的性能。 如何让APP具备IM性能,个别有如下三种解决方案: 第一:自研。IM是一个看起来门槛很低的我的项目,网上有很多所谓的IM开发教程,甚至很多毕业生的毕业设计也是做一个IM零碎。因为这个误会,很多企业主或者项目经理盲目乐观组建3-5集体的IM团队,历时一年半载,最初只实现了一个demo版本。因为架构设计不合理,demo版本存在音讯失落、零碎异样等bug,远远达不到商业化的要求。 第二:应用IM云服务商的SDK。很多企业自研IM这条路走不通,IM云服务商看到了商业机会,通过提供IM SDK和API的形式,让开发者简略集成IM性能。当然这里也存在显著的问题。(1)老本问题:企业每年额定领取上万乃至数十万的云服务费用,是个不小的老本;(2)数据隐衷问题:企业的用户数据、聊天记录等外围数据存储在IM云服务商,如何保证数据的安全性是个极大挑战;(3)需要定制问题:IM需要多样化,IM性能只能由IM云服务商通过SDK的模式提供给大家应用,对于一些定制化的需要,是否反对,什么时候实现,都是个未知数;(4)云服务商绑架问题:一旦应用IM云服务,造成捆绑关系,迁徙老本高,受制于人。 第三:应用开源IM。github上IM开源我的项目不少,但开发者却很难应用,次要有几点起因(1)集体我的项目居多,尽管有些我的项目也有几k star,但近几年都无人保护,真正的商业化产品不敢应用;(2)大部分我的项目不是IM技术业余团队实现的,技术实力和技术架构存疑,也没有通过大我的项目和海量用户测验;(3)只开源服务端或者客户端,只开源某一端,须要开发者实现另外一端,研发老本同样不小,另外,开源我的项目大部分都是以独自的聊天产品开源,开发者如何把IM集成到本身app中,同样存在大量的批改和适配老本。(4)局部开源我的项目免费版性能缺失,商业版免费。 Open-IM劣势(1)前微信技术专家打造,多年IM从业教训。优良的技术架构,禁受过海量用户测验; (2)残缺组件,一键部署,轻松集成。客户端提炼成不便集成的SDK,服务端通过docker一键部署,经营管理系统展现后盾数据; (3)全开源,不存在任何闭源免费版本。减少开源社区的参加积极性,产生黏性、惯性、认同感、归属感以及忠诚度,引入更多技术极客,进一步欠缺Open-IM; (4)社区版收费,给初创企业每年节俭上万费用。对于应用IM云服务的企业,每年能够节俭上万乃至数十万费用; (5)私有化部署,无任何关联。开发者一键部署Open-IM在自家服务器上,齐全解脱了对第三方的依赖,数据隐衷可控、有保障; (6)不便定制,采纳“所有皆音讯”的通信模型。代码开源,对于自定义需要,开发者能够批改客户端代码轻松实现; (7)高性能、微服务、集群化。零碎具备平行扩大能力,反对服务注册、服务发现。满足初创企业简略一键部署需要,同时也满足中大型企业集群化部署需要。 (8)收取技术服务费,打造久远、衰弱的商业模式。对于开发者来说,能够收费应用咱们社区版的全副技术和代码。对于高标准的开发者,能够应用咱们的专业版,订阅咱们的技术服务,咱们为之提供更业余的技术服务、咨询服务和私有化部署服务。 咱们的使命从公司成立之初就将“开源”作为外围策略来推动,开源充分体现了自在、平等、分享的互联网精力。 寰球范畴频繁产生的数据泄露、勒索病毒、隐衷滥用等安全事件一次次给企业敲响警钟,企业管理者对数据资产的价值、数据安全的重要性有了更清晰的意识,数据安全成就企业外围价值。 IM作为外围业务数据,平安的重要性毋庸置疑,OpenIM开源以及私有化部署让企业能更放心使用。 现在IM云服务商免费高企,如何让企业低成本、平安、牢靠接入IM服务,是OpenIM的历史使命,也是咱们后退的方向。 咱们的团队开创团队来自前微信高级架构师、IM/WebRTC专家团队,咱们致力于用开源技术发明服务价值,打造轻量级、高可用的IM架构,开发者只需简略调用 SDK,即可在利用内构建多种即时通讯及实时音视频互动场景。 ...

September 17, 2021 · 1 min · jiezi

关于im:OpenIM原创IM服务端docker源码集群部署-非常实用

写在后面Open-IM是由前微信技术专家打造的开源的即时通讯组件。Open-IM包含IM服务端和客户端SDK,实现了高性能、轻量级、易扩大等重要个性。开发者通过集成Open-IM组件,并私有化部署服务端,能够将即时通讯、实时网络能力疾速集成到本身利用中,并确保业务数据的安全性和私密性。 开创团队来自前微信高级架构师、IM/WebRTC专家团队,咱们致力于用开源技术发明服务价值,打造轻量级、高可用的IM架构,开发者只需简略调用 SDK,即可在利用内构建多种即时通讯及实时音视频互动场景。 IM作为外围业务数据,平安的重要性毋庸置疑,OpenIM开源以及私有化部署让企业能更放心使用。 现在IM云服务商免费高企,如何让企业低成本、平安、牢靠接入IM服务,是OpenIM的历史使命,也是咱们后退的方向。 理解更多原创文章:【OpenIM原创】开源OpenIM:轻量、高效、实时、牢靠、低成本的音讯模型 【OpenIM原创】C/C++调用golang函数,golang回调C/C++函数 【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理 【OpenIM扩大】OpenIM服务发现和负载平衡golang插件:gRPC接入etcdv3 【开源OpenIM】高性能、可伸缩、易扩大的即时通讯架构 如果您有趣味能够在文章结尾理解到更多对于咱们的信息,期待着与您的交换单干。1.克隆git clone https://github.com/OpenIMSDK/Open-IM-Server.git2.装置cd Open-IM-Serverdocker-compose pull3.启动docker-compose up4.查看docker-compose ps 如图所示,示意失常启动。 源码部署装置组件Open-IM-Server依赖五大开源组件:Etcd、MySQL、MongoDB、Redis、Kafka,在应用源码部署Open-IM-Server 前,请确保五大组件已装置。如果没有装置以上组件,倡议应用上文的docker部署。 1.克隆我的项目git clone https://github.com/OpenIMSDK/Open-IM-Server.git2.批改config.yaml,配置五大组件的连贯参数cd Open-IM-Servervim config.yaml批改 Etcd 配置项etcd: etcdAddr: [ 127.0.0.1:2379 ]批改MySQL配置项mysql: dbAddress: [ 127.0.0.1:3306 ] dbUserName: root dbPassword: openIM批改MongoDB配置项 mongo: dbAddress: [ 127.0.0.1:27017 ] dbUserName: dbPassword: 批改 Redis配置项 redis: dbAddress: [ 127.0.0.1:6379 ] dbPassWord: openIM批改 Kafka 配置项kafka: ws2mschat: addr: [ 127.0.0.1:9092 ] ms2pschat: addr: [ 127.0.0.1:9092 ]保留config.yaml退出即可。 每种RPC数量默认为1,如果须要调整RPC数量,批改config.yaml中的配置项rpcport对应的port信息,port个数代表对应rpc服务的过程数。比方openImUserPort: [ 10100,10101 ]示意本机会启动两个open_im_user,port别离为10100,10101 ...

September 17, 2021 · 1 min · jiezi

关于im:Flutter-IM跨端架构设计和实现

本文由阿里闲鱼技术团队祈晴分享,原文参考微信公众号淘系技术,感激作者的技术分享。OpenIMgithub开源地址: https://github.com/OpenIMSDK/... OpenIM官网 :https://www.rentsoft.cn OpenIM官方论坛:https://forum.rentsoft.cn/ 现状 闲鱼IM框架构建于2016-2017年,期间屡次迭代降级导致历史包袱累积多,后经IM界面Flutter化,造成架构更简单。 开发层面总结闲鱼以后架构次要存在如下几个问题: 研发效率较低:以后架构开发需要波及到Android/iOS双端的逻辑代码以及Flutter的UI界面代码,定位问题往往只能从Flutter UI表象追究到Native逻辑破绽;架构档次较差:架构设计上分层不清晰,业务逻辑夹杂在外围的逻辑层以致代码变更危险大;性能测试略差:外围数据源存储Native内存,需经Flutter Plugin将数据源序列化上抛Flutter侧,在大批量数据源状况下性能体现较差;从舆情层面总结闲鱼IM以后架构的次要问题如下: 定位问题艰难:线上舆情反馈千奇百怪,测试始终无奈复现相干场景,因而很多时候只能靠景象猜想实质;疑难杂症较多:架构不稳定性造成呈现的问题重复呈现,以后疑难杂症次要包含未读红点计数,iPhone5C低端机器架构,以及多媒体发送等多个问题;问题差异性大:Android和iOS两端逻辑代码差别大,包含现存埋点逻辑都不尽相同,因而排查问题本源时候双端都会有不同问题根因,解决问题计划也不雷同;业界跨端计划 为解决以后IM痛点,闲鱼往年特起对于IM架构降级我的项目,重在解决客户端中双端一致性痛点,初步构想计划就是实现跨端对立的Android/iOS逻辑架构; 在以后行业内跨端计划可初步归类如下图架构,在GUI层面的跨端计划有Weex,ReactNative,H5,Uni-APP等,其内存模型大多须要通过桥接到Native模式存储; 在逻辑层面的跨端计划大抵有C/C++等与虚拟机无关语言实现跨端,当然汇编语言也可行; 此外有两个独立于上述体系之外的架构就是Flutter和KMM(谷歌基于Kotlin实现相似Flutter架构),其中Flutter运行特定DartVM,将内存数据挂载其本身的isolate中; 思考闲鱼是Flutter的前沿探索者,计划上优先应用Flutter; 然而Flutter的isolate更像一个过程的概念(底层实现非应用过程模式),相比Android,同一过程场景中,Android的Dalvik虚拟机多个线程运行共享一个内存Heap,而DartVM的Isolate运行隔离各自的Heap,因此isolate之间通信形式比拟繁琐(需通过序列化反序列化过程); 整个模型如下图所示: 若按官网混合架构实现Flutter利用,开启多个FlutterAcitivty/FlutterController,底层会生成多个Engine,对应会存在多个isolate,而isolate通信相似于过程通信(相似socket或AIDL),这里借鉴闲鱼FlutterBoost的设计理念,FlutterIM架构将多个页面的Engine共享,则内存模型就人造反对共享读取, 原理图如下: Flutter IM 架构设计 ▐ 新老架构比照如下图是一个老架构计划,其外围问题次要集中于Native逻辑形象差,其中逻辑层面还设计到多线程并发使得问题倍增,Android/iOS/Flutter交互繁冗,开发保护老本高,核心层耦合较为重大,无插拔式概念; 思考到历史架构的问题,演进如下新架构设计: 架构从上至下顺次为业务层,散发层,逻辑层以及数据源层,数据源层来源于推送或网络申请,其封装于Native层,通过Flutter插件将音讯协定数据上抛到Flutter侧的外围逻辑层,解决实现后变成Flutter DB的Enitity实体,实体中挂载一些音讯协定实体; 外围逻辑层将繁冗数据扁平化打包挂载到散发层中的会话内存模型数据或音讯内存模型数据,最初通过观察者模式的订阅散发到业务逻辑中; Flutter IM重点集中革新逻辑层和散发层,将IM外围逻辑和业务层面数据模型进行封装隔离,外围逻辑层和数据库交互后将数据封装到散发层的moduleData中,通过订阅形式散发到业务层数据模型中; 此外在IM模型中DB也是重点依赖的,集体对DB数据库治理进行全面封装解,实现一种轻量级,性能佳的Flutter DB治理框架; ▐ DB存储模型Flutter IM架构的DB存储依赖数据库插件,目前支流插件是Sqflite,其存储模型如下: 根据上图Sqflite插件的DB存储模型会有2个期待队列,一个是Flutter层同步执行队列,一个是Native层的线程执行队列,其Android实现机制是HandlerThread,因而Query/Save读写在会同一线程队列中,导致响应速度慢,容易造成DB SQL沉积,此外缺失缓存模型,于是集体定制如下改良计划: Flutter侧通过表的主键设计查问时候会优先从Entity Cache层去获取,若缓存不存在,则通过Sqflite插件查问,同时革新Sqflite插件成反对sync/Async同步异步两种形式操作,对应到Native侧也会有同步线程队列和异步线程队列,保证数据吞吐率; 然而这里倡议查问应用异步,存储应用同步更稳当,次要怕呈现多个雷同的数据元model同一时间进入异步线程池中,存储先后顺序无奈无效的保障; ▐ ORM数据库计划 IM架构重度依赖DB数据库,而以后业界还没有一个齐备的数据库ORM治理计划,参考了Android的OrmLite/GreenDao,集体自行设计一套Flutter ORM数据库治理计划,其核心思想如下: 因为Flutter不反对反射,因而无奈间接像Android的开源数据库形式操作,但可通过APT形式,将Entity和Orm Entity绑定于一身,操作OrmEntity即操作Entity,整个代码格调设计也和OrmLite极其类似,参考代码如下: ▐ IM内存数据模型FlutterIM架构在内存数据模型次要划分为会话和音讯两个颗粒度,会话内存数据模型交托于SessionModuleData,音讯内存数据模型交托于MessageModuleData; 会话内存数据有一个根节点RootNotice,而后其挂载PSessionMessageNotice(这里PSessionMessageNotice是ORM映射的会话DB表模型)子节点汇合; 音讯内存数据会有一个MessageConatiner容器治理,其外部挂载此会话中的PMessage(PMessage是ORM映射的音讯DB表模型)音讯汇合。 根据上一章节,PSessionMessageNotice设计了一个OrmEnitity Cache,思考到IM中会话数是无限的,因而PSessionMessageNotice都是间接缓存到Cache中,这种做法的益处是各地去拿会话数据元时候都是缓存中同一个对象,容易保障多次重复读写的数据一致性; 而PSessionMessageNotice思考到其数量能够有限多的特殊性,因而这里将其挂载到MessageContainer的内存治理中,在退出会话的时机会校验容器中PMessage汇合的数量,适当缩容能够缩小内存开销,模型如下图所示: ▐ 状态治理计划Flutter IM状态治理计划比较简单,对数据源Session/Message维度应用观察者模式的订阅散发形式实现,架构相似于EventBus模式,页面级的状态治理无论应用fish-redux,scopeModel或者provider简直影响面不大,外围还是需保留一种插拔式形象更重要;架构如下图: ...

September 15, 2021 · 1 min · jiezi

关于im:微信陌陌等著名IM软件设计架构详解

本文由作者jinglijun编写批改,出处链接:https://blog.csdn.net/justinj... OpenIMgithub开源地址: https://github.com/OpenIMSDK/... OpenIM官网 :https://www.rentsoft.cn OpenIM官方论坛:https://forum.rentsoft.cn/ 对微信、陌陌等进行了剖析,收回来分享一下(工夫有些久了) 电量:对于挪动设施最大的瓶颈就是电量了。因为用户不可能随时携带电源,充电宝。所以必须思考到电量问题。那就要查看咱们工程是不是有后盾运行,心跳包发送工夫是不是正当。 网络: 这个也是IM最外围的内容了,咱们要做到在任何网络下等顺畅聊天那就不容易了,好多公司都用的xmpp框架,如果在强网络环境下,xmpp齐全没有问题。然而那种弱网络环境下xmpp就大刀阔斧啦,用户体验就很垃圾了。 集体感觉xmpp 能够玩玩(参考看这个RFC3920和RFC3921 ), 然而用来真正的产品就差远了。如果遇到一个做IM 的敌人张口闭口都说xmpp 的话,那么不必沟通了,必定不是什么好产品。微信、QQ以前也曾用过xmpp,然而最初也放弃了xmpp,就晓得xmpp有很多弊病了,还有就是报文太大,好臃肿,节约流量。为了保障稳固,微信用了长链接和短链接相结合,例如: 1 ,两个域名 微信划分了http模式(short链接)和 tcp 模式(long 链接),别离应答状态协定和数据传输协定 long.weixin.qq.com dns check (112.64.237.188 112.64.200.218) short.weixin.qq.com dns check ( 112.64.237.186 112.64.200.240) 2 ,阐明 2.1 short.weixin.qq.com 是HTTP协定扩大,运行8080 端口,http body为二进制(protobuf)。 主要用途(接口): 用户登录验证; 好友关系(获取,增加); 音讯sync (newsync),自有sync机制; 获取用户图像; 用户登记; 行为日志上报。 朋友圈发表刷新 2.2 long.weixin.qq.com tcp 长连贯, 端口为8080,相似微软activesync的二进制协定。 主要用途(接口): 承受/发送文本音讯; 承受/发送语音; 承受/发送图片; 承受/发送视频文件等。 所有下面申请都是基于tcp长连贯。在发送图片和视频文件等时,分为两个申请;第一个申请是缩略图的形式,第二个申请是全数据的形式。 2.2.1 数据报文方面 增量上传策略: 每次8k左右大小数据上传,服务器确认;在持续传输。 图片上传: 先传缩略图,传文本音讯,再传具体文件 下载: 先下载缩略图, 在下载原图 下载的时候,全部一次推送。 ...

September 15, 2021 · 2 min · jiezi

关于im:闲鱼消息发展回顾

简介: 转自闲鱼技术 作者:今朝 、有攸 OpenIMgithub开源地址: https://github.com/OpenIMSDK/... OpenIM官网 :https://www.rentsoft.cn OpenIM官方论坛:https://forum.rentsoft.cn/ 引言闲鱼音讯零碎通过几代开发的建设,目前稳固的撑持亿级音讯体量。在音讯零碎建设过程中,咱们经验了从简略到简单,从困扰到破局,每一次的技术扭转都是为了更好的解决当下业务面临的问题。“忆昔午桥桥上饮,坐中多是豪英“,此文记录闲鱼音讯零碎技术变迁,以期在此基础上吸取更多教训。 闲鱼音讯1.0:业务初创期,最小化可用背景:14年启动闲置交易独立APP “闲鱼”,一期构建实现APP主链路,蕴含商品公布→搜寻→商品详情→IM会话→交易。作为初创app,业务需尽快上线验证成果,技术建设上须要实现闲鱼音讯从无到有的零碎搭建。 作为即时通讯零碎,最小化能力蕴含 音讯存储:会话、摘要、音讯音讯同步:推、拉音讯通道:长连贯、厂商推送与个别IM会话模型不同的是,闲鱼会话以商品为主体,人+人+商品为因素构建会话,因会话模型的差别,淘系已有的音讯零碎,短期内无奈满足业务需要,而闲鱼齐全自建音讯零碎耗时微小。为了保障业务高效上线,技术选型上最大化复用已有零碎能力,防止反复造轮子。所以, 数据模型与底层存储依赖淘系私信体系进行建设;音讯数据获取上,客户端全量从服务端拉取音讯数据通信协定应用来往SDK及mtop总体架构如下图,以此模式实现疾速交付保障了业务最小化可用 闲鱼音讯2.0:用户量高增速,重建闲鱼音讯零碎背景: 闲鱼用户量疾速冲破100W,音讯服务调用量暴涨。常态性的,用户反馈音讯数据获取卡顿、白屏,大量的push发送下,零碎告警频发。 造成这些问题的起因:音讯1.0 模式下,获取音讯数据全量拉模式,客户端纯UI不做数据存储 当用户须要查看音讯数据时,数据拉取胜利与否取决于网络、数据访问速度,偶发性的造成卡顿、白屏中心化的数据存储,读远大于写,高并发下,服务端负载过大比方1W个用户同时在线聊天,依照以后架构并发拉取全量音讯,估算5Wqps. 无妨假如,同时在线聊天用户数10W时,对服务端压力可想而知基于上述问题,咱们决定重建音讯零碎,以应答将来更大的用户增量。回归到IM零碎的外围性能音讯存储模型:会话模型:由owner、itemid、user、sessionType 来标识惟一会话,减少扩大属性反对个性化摘要模型:作为用户会话视图,同一会话的不同用户可个性化出现,由userid、sid标识惟一摘要音讯模型:由sender、音讯内容、音讯版本、sid组成。sid+音讯版本惟一确定一条音讯指令模型:是一种双端约定,由服务端下发,客户端执行的指令集。如免打搅指令、删除指令等音讯通道:在线通道:应用淘宝无线ACCS长连贯提供的全双工、低延时、高平安的通道服务。离线通道:应用淘宝音讯推送平台AGOO. 其屏蔽了各支流厂商对接的复杂度,间接对业务零碎提供服务音讯同步模型:1.客户端建设数据库,存储音讯数据 当音讯数据存储在本地设施上,音讯同步从全量拉取优化为全量+增量同步联合的模式。 增量同步:客户端存储音讯位点信息,通过与服务端最新位点比拟,仅同步增量音讯;全量同步:当用户卸载重装或位点gap过大时,客户端全量拉取历史音讯数据,进行端上数据重建2.服务端建设集体音讯域环(收件箱模型),以和客户端进行增量数据同步。同时,音讯1.0版本存在的读多写少的问题,通过集体域环的写扩散来均衡读写压力 下图为一条音讯从发送到接管的过程以及服务端和客户端的执行流程 如图所示,假如Ua给Ub发送一条音讯,音讯写扩散至Ua和Ub的各自的域环中。1.当客户端online时,接管到推送的音讯位点=以后端上域版本+1,本地音讯数据库merge即可2.当客户端offline时,仅进行离线推送告诉,当用户从新上线时,进行数据同步,由服务端判断触发增量同步还是全量同步 &nbsp;&nbsp;&nbsp;&nbsp;如果域环版本差值小于阀值,增量同步后,进行本地音讯数据库merge &nbsp;&nbsp;&nbsp;&nbsp;当域环版本差值大于阀值,进行全量音讯拉取,做端上数据重建整个同步逻辑基于闲鱼的音讯域环,域环能够看作是有着固定容量的用户音讯收件箱,给一个用户发送的所有音讯都会同步到他的域环中。域环存储:域环须要反对高并发数据读写,应用阿里分布式KV存储系统tair来实现域环容量:为缩小全量音讯同步,以用户下次进入闲鱼须要同步的均匀音讯量来布局集体域环容量。同时利用FIFO循环笼罩历史数据域环版本:用户以后音讯位点,在音讯进入集体域环时通过tair的counter实现域环版本严格间断递增,用于全量、增量同步判断 上述建设实现后,闲鱼具备了本人独立的音讯零碎,当下遇到的问题失去了缓解,用户体验度有大幅晋升。 闲鱼音讯3.0:业务疾速倒退下,零碎稳定性保障背景: 随着闲鱼业务生态的丰盛,IM会话与音讯内容类型一直扩大,同时在DAU的快速增长下,用户反馈音讯收不到、音讯提早等舆情问题日渐突出。 问题剖析:1.闲鱼app过程无无效保活机制,app退到后盾后过程很快就会被零碎挂起,导致长连贯中断。此时音讯推送走厂商通道,而厂商通道的实时性较差,且对音讯推送的优先级设定有差别,从而造成用户感知音讯提早2.accs在线音讯推送时,均匀延时较短,但存在假连状况,而且目前的音讯推送链路无ack机制,造成服务端认为音讯收回去了但实际上客户端并没有收到,用户下次关上app后能力看到音讯,用户感知音讯提早。造成假连贯的起因:用户退到后盾,accs长连中断,然而设施状态更新有延时。3.目前音讯同步的推模式(accs push)、拉模式(mtop),客户端未做隔离,异步进行解决,导致在某些极其状况下音讯数据库解决异样,引发音讯失落。比方某用户上线后间断收到多条音讯,其中一条触发域黑洞,在进行音讯同步端上数据重建时,小概率解决出错。4.大部分线上音讯问题发现靠舆情反馈,如音讯错乱,出问题后零碎无感知、无补救措施且排查艰难,仅能追随版本做修复5.业务不断丰富,孵化出基于音讯零碎的服务号及小程序内容营销、音讯群组等,各类音讯发送链路共用域环与数据存储,造成稳定性问题。如集体域环的音讯包含IM聊天和营销音讯,IM聊天由用户触发,须要保障强达到;而营销音讯个别是由零碎通过班车等形式批量发送,音讯量级大,tps高,影响IM服务稳定性 基于上述剖析,咱们进行专项解决:音讯重发与推拉隔离ACK: 保障音讯及时达到。服务端上行accs音讯时,将音讯退出重试队列并提早重试,客户端在收到accs音讯并解决胜利后,给服务端回一个ack,服务端收到ack后更新音讯达到状态,并终止重试,以此防止设施假连或网络不稳固的状况。重发:依据提早重发策略决定何时重发消息,保障音讯确定性达到。自适应提早重发策略是指新音讯先通过4次固定N秒的短提早来探测设施的网络情况,而后依据网络情况来递增固定步长M的提早策略,这种策略能够保障在最短的工夫内,应用起码的重发次数将音讯投递胜利。音讯队列:端上引入音讯队列,按程序解决音讯,保障音讯解决的准确性。同时进行推拉隔离,保障队列有序生产,解决了简单情况下并发解决音讯数据合并出错的问题。 数据存储拆分闲鱼每天发送的音讯中有一半以上是营销音讯,营销音讯的发送具备显著的波峰波谷流量,高峰期会导致音讯数据库抖动,影响IM音讯。对音讯、摘要、域环存储做业务隔离,以适应不同业务场景对稳定性不同的要求。 IM音讯须要极高的稳定性保障,其音讯及摘要持续应用mysql存储营销音讯存储周期短,稳定性要求低于IM,采纳Lindorm存储。Lindorm是一种多模型的云原生数据库服务,具备成本低、自定义TTL、容量横向扩大等劣势域环做实例级别隔离,保障IM域环的容量不会被其余音讯占用,从而影响到音讯同步 线上问题发现与复原保障稳定性的要害因素是做好各种外围指标的监控,而监控首先要有数据起源,对服务端+客户端的要害链路节点埋点,基于团体UT、SLS,通过blink进行实时荡涤、计算,最终造成对立标准的日志数据落至SLS,以供实时监控及链路排查。音讯零碎的外围指标是保障用户音讯发的出、收失去且及时收到,所以咱们通过计算发送成功率、达到率、音讯提早来监控零碎的稳定性。此外,为了解决用户舆情排查艰难的问题 咱们设计了一套指令集,通过约定指令协定,服务端向指定用户下发指令,客户端执行对应指令进行异样数据上报,进步排查效率扩大了强制全量同步、数据校对等指令,定向修复用户音讯数据问题,相较以往呈现重大bug只能让用户卸载重装解决,这种形式显然对用户是更敌对的 通过一系列专项治理,技术类舆情降落50%,从0到1建设了音讯稳定性体系,用户体验进一步晋升。 最初:宏大的用户体量下,谋求极致的NPS闲鱼作为电商交易APP, 其中IM是交易的前置链路,IM的产品体验极大影响用户交易效率前段时间进行用户调研,从闲鱼IM NPS低于预期(NPS是用户忠诚度掂量指标 = 推荐者%-贬损者%),从用户反馈来看: 局部用户对产品性能有较强烈的诉求,诸如音讯搜寻、分组等大部分用户对发送音讯过程中的违规问题难以了解仍有较多舆情反馈音讯收不到或提早映射到目前闲鱼的音讯零碎上,咱们的零碎架构仍然有很多须要继续改良的中央。典型的如同步协定冗余,在需要迭代过程中容易引发问题、无效保活机制的缺失对音讯即时送达的影响、小众机型离线音讯收不到、多年的数据积攒在线库臃肿等问题,影响着闲鱼业务迭代速度与NPS。将晋升NPS作为外围指标,闲鱼音讯4.0进行时.... OpenIM官网 :https://www.rentsoft.cn OpenIM官方论坛:https://forum.rentsoft.cn/ 更多原创技术文章: 开源OpenIM:高性能、可伸缩、易扩大的即时通讯架构https://forum.rentsoft.cn/thr... 【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理https://forum.rentsoft.cn/thr... 【OpenIM原创】开源OpenIM:轻量、高效、实时、牢靠、低成本的音讯模型 https://forum.rentsoft.cn/thr... OpenIM服务发现和负载平衡golang插件:gRPC接入etcdv3 https://forum.rentsoft.cn/thr... 【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理 https://forum.rentsoft.cn/thr... 【OpenIM原创】C/C++调用golang函数,golang回调C/C++函数 https://forum.rentsoft.cn/thr...

September 15, 2021 · 1 min · jiezi

关于im:一个通用即时通讯IM系统的设计

本文章参考https://systeminterview.com/d...,有删减。 在本章中,咱们将探讨聊天零碎的设计。简直每个人都应用聊天应用程序。图12-1显示了市场上一些最风行的应用程序。 聊天利用为不同的人执行不同的性能。确定确切的要求是极其重要的。例如,当面试官思考一对一聊天时,您不心愿设计一个专一于个体聊天的零碎。摸索性能需要是很重要的。 步骤1-确定需要当然,世界上没有最完满的架构,只有最合适的架构,也没有所谓的通用计划,不同的解决方案都有其优缺点,只有最满足业务的零碎才是一个好的零碎。而且,在无限的人力、物力,综合思考工夫老本,通常须要做出很多衡量。 就要设计的聊天应用程序的类型达成统一至关重要。在市场上,有Facebook Messenger、微信和WhatsApp等一对一聊天利用,Slack等专一于群聊的office聊天利用,Discord等专一于大群体互动和低语音聊天提早的游戏聊天利用。 第一组廓清问题应该明确面试官在要求你设计聊天零碎时的具体想法。至多,弄清楚你是应该专一于一对一聊天还是群聊利用。您可能会问以下问题: 候选人:咱们应该设计什么样的聊天应用程序?1对1还是基于组?面试官:它应该反对1对1和群聊。 候选人:这是一个挪动应用程序吗?还是网络应用?或者两者都有?面试官:都有。 候选人:这个应用程序的规模是多少?守业利用还是大规模?面试官:它应该反对5000万每日沉闷用户(DAU)。 候选人:对于群组聊天,群组成员限度是多少?面试官:最多100人 候选人:聊天应用程序的重要性能是什么?它能反对附件吗?面试官:1对1聊天,群聊,在线指示器。零碎仅反对文本音讯。 候选人:邮件大小有限度吗?面试官:是的,文本长度应该少于100000个字符。 候选人:须要端到端加密吗?面试官:当初不须要,但如果工夫容许,咱们会探讨的。 候选人:咱们应该将聊天记录存储多久?面试官:永远。 在本章中,咱们将重点设计一款相似Facebook messenger的聊天应用程序,重点介绍以下性能: •一对一聊天,传递提早低 •小组聊天(最多100人) •在线状态 •多设施反对。同一帐户能够同时登录到多个帐户。 •推送告诉 就设计规模达成统一也很重要。咱们将设计一个反对5000万DAU的零碎。 第2步-设计为了开发高质量的设计,咱们应该具备客户机和服务器如何通信的基本知识。在聊天零碎中,客户端能够是挪动应用程序或web应用程序。客户机之间不间接通信。相同,每个客户端都连贯到一个聊天服务,该服务反对上述所有性能。让咱们关注根本业务。聊天室服务必须反对以下性能: •接管来自其余客户端的音讯。 •为每条音讯找到适合的收件人,并将音讯转发给收件人。 •如果收件人不在线,则在服务器上保留该收件人的音讯,直到其在线。 图12-2显示了客户端(发送方和接管方)与聊天服务之间的关系。 当客户端打算启动聊天时,它会应用一个或多个网络协议连贯聊天服务。对于聊天服务,网络协议的抉择很重要。让咱们和面试官讨论一下。 对于大多数客户机/服务器应用程序,申请由客户机发动。对于聊天应用程序的发送方来说也是如此。在图12-2中,当发送方通过聊天服务向接管方发送音讯时,它应用通过工夫测试的HTTP协定,这是最常见的web协定。在此场景中,客户端关上与聊天服务的HTTP连贯并发送音讯,告诉服务将音讯发送给接管方。keep-alive在这方面很无效,因为keep-alive头容许客户端与聊天服务放弃长久连贯。它还缩小了TCP握手的次数。HTTP在发送方是一个很好的抉择,许多风行的聊天应用程序(如Facebook[1])最后应用HTTP发送音讯。 然而,接收器端要简单一些。因为HTTP是由客户机发动的,因而从服务器发送音讯并不简略。多年来,许多技术被用来模仿服务器启动的连贯:轮询、长轮询和WebSocket。这些都是零碎设计面试中宽泛应用的重要技巧,所以让咱们来钻研一下它们。 轮询如图12-3所示,轮询是一种客户端定期询问服务器是否有可用音讯的技术。依据轮询频率,轮询的老本可能会很高。它可能会耗费贵重的服务器资源来答复一个在大多数状况下都没有答案的问题。 长轮询因为轮询可能效率低下,下一步是长轮询(图12-4)。 在长轮询中,客户端放弃连贯关上,直到有新音讯可用或达到超时阈值。一旦客户端接管到新音讯,它会立刻向服务器发送另一个申请,从而重新启动过程。长轮询有几个毛病: •发送方和接管方可能无奈连贯到同一聊天服务器。基于HTTP的服务器通常是无状态的。如果应用循环法进行负载平衡,则接管音讯的服务器可能与接管音讯的客户端没有长轮询连贯。 •服务器无奈很好地判断客户端是否已断开连接。 •效率低下。如果用户聊天不多,长轮询依然会在超时后进行定期连贯。 websocket长连贯WebSocket是从服务器向客户端发送异步更新的最常见解决方案。图12-5显示了其工作原理。 WebSocket连贯由客户端启动。它是双向和长久的。它从HTTP连贯开始,能够通过一些定义良好的握手“降级”到WebSocket连贯。通过这种长久连贯,服务器能够向客户端发送更新。即便有防火墙,WebSocket连贯通常也能失常工作。这是因为它们应用的端口80或443也被HTTP/HTTPS连贯应用。 后面咱们说过,在发送方应用HTTP是一种很好的协定,然而因为WebSocket是双向的,因而没有强有力的技术理由不将其用于发送。图12-6显示了如何将WebSocket(ws)用于发送方和接管方。 通过将WebSocket用于发送和接管,它简化了设计,并使客户端和服务器上的实现更加简略。因为WebSocket连贯是长久的,因而高效的连贯治理在服务器端至关重要。 高级设计方才咱们提到WebSocket被选为客户端和服务器之间双向通信的次要通信协议,须要留神的是,其余所有都不用是WebSocket。事实上,聊天应用程序的大多数性能(注册、登录、用户配置文件等)都能够通过HTTP应用传统的申请/响应办法。让咱们深刻理解一下零碎的高级组件。 如图12-7所示,聊天零碎分为三大类:无状态服务、有状态服务和第三方集成。 无状态服务无状态服务是传统的面向公众的申请/响应服务,用于治理登录、注册、用户配置文件等。这些是许多网站和应用程序的常见性能。 无状态服务位于负载平衡器前面,负载平衡器的工作是依据申请门路将申请路由到正确的服务。这些服务能够是繁多的或单个的微服务。咱们不须要本人构建这些无状态服务中的许多,因为市场上存在能够轻松集成的服务。咱们将深刻探讨的一项服务是服务发现。它的次要工作是为客户端提供一个能够连贯到的聊天服务器的DNS主机名列表。 有状态服务惟一有状态的服务是聊天服务。该服务是有状态的,因为每个客户端都放弃与聊天服务器的长久网络连接。在该服务中,只有服务器依然可用,客户端通常不会切换到另一个聊天服务器。服务发现与聊天服务密切配合,以防止服务器过载。咱们将深入探讨细节。 第三方集成对于聊天应用程序,推送告诉是最重要的第三方集成。这是一种在新音讯达到时告诉用户的办法,即便应用程序未运行。推送告诉的正确集成至关重要。无关更多信息,请参阅第10章设计告诉零碎。 可伸缩性在小范畴内,下面列出的所有服务都能够装置在一台服务器中。即便依照咱们设计的规模,实践上也能够在一台古代云服务器中包容所有用户连贯。服务器能够解决的并发连接数很可能是限度因素。在咱们的场景中,在一百万并发用户的状况下,假如每个用户连贯在服务器上须要10K的内存(这是一个十分粗略的数字,并且十分依赖于语言选择),它只须要大概10GB的内存就能够在一个框中包容所有连贯。 如果咱们提出一个设计,所有的货色都放在一台服务器上,这可能会在面试官的脑海中升起一个微小的危险信号。没有一个技术专家会在一台服务器上设计这样的规模。因为许多因素,单服务器设计是交易的破坏者。单点故障是其中最大的故障。 然而,从繁多服务器设计开始是完全正确的。确保面试官晓得这是一个终点。将咱们提到的所有内容放在一起,图12-8显示了调整后的高级设计。 在图12-8中,客户端放弃与聊天服务器的长久WebSocket连贯,以进行实时消息传递。 •聊天服务器便于发送/接管音讯。 •状态服务器治理在线/离线状态。 •API服务器解决所有,包含用户登录、注册、更改配置文件等。 •告诉服务器发送推送告诉。 •最初,键值存储用于存储聊天历史记录。当离线用户联机时,她将看到以前的所有聊天记录。 存储当初,咱们曾经筹备好了服务器,服务正在运行,第三方集成曾经实现。在技术层的深处是数据层。数据层通常须要一些致力能力使其正确。咱们必须做出的一个重要决定是抉择正确的数据库类型:关系数据库还是NoSQL数据库?为了做出理智的决定,咱们将查看数据类型和读/写模式。 典型的聊天零碎中存在两种类型的数据。第一种是通用数据,例如用户配置文件、设置、用户好友列表。这些数据存储在强壮牢靠的关系数据库中。复制和分片是满足可用性和可伸缩性要求的罕用技术。 第二个是聊天零碎特有的:聊天历史数据。了解读/写模式很重要。 •聊天零碎的数据量微小。此前的一项钻研[2]显示,Facebook messenger和Whatsapp每天解决600亿条音讯。 ...

September 14, 2021 · 1 min · jiezi

关于im:SoCC2018论文DAGOR微信大规模微服务过载控制系统

大规模在线服务零碎的无效过载管制对于避免零碎后端过载至关重要,微信团队自研的过载管制计划DAGOR曾经在微信业务零碎中运行了五年多,为微信后端的衰弱倒退提供了重要的保障。 DAGOR的论文发表在SoCC2018,本文为该论文的中文翻译版本,英文版本在(https://arxiv.org/pdf/1806.04...),对原文感兴趣的同学能够点击”。 摘要大规模在线服务零碎的无效过载管制对于避免零碎后端过载至关重要。通常,过载管制的设计是针对单个服务的。然而因为简单的服务依赖或服务实现的缺点,特定于服务的过载管制可能会对整个零碎造成侵害。在服务开发过程中,开发人员通常难以精确地预估理论工作负载的变动。因而,过载管制与服务逻辑拆散显得至关重要。本文针对面向帐户的微服务体系结构提出了一种过载管制计划DAGOR。DAGOR是服务无感知并且以零碎为核心的。它从微服务粒度上治理过载,从而使得每个微服务可能实时地监控其负载状态,并且当检测到过载时,可能和相干服务通过合作形式触发减载(load shedding)。DAGOR曾经在微信后盾应用了5年。试验结果表明,DAGOR可能在零碎过载时取得较高的服务成功率,同时保障过载管制的公平性。 关键词过载管制,服务准入管制,微服务架构,微信 1. 介绍过载管制旨在加重零碎呈现过载时的服务无响应。这对于须要确保实现24×7服务可用性的大规模在线应用程序来说是至关重要的,只管呈现了不可预测的负载激增。尽管云计算有助于按需配置,但仍无奈解决过载问题——服务提供商受到其可从云提供商处购买的计算资源的限度,因而云提供商须要对其提供的云服务进行过载管制。 传统用于简略服务架构的过载管制假设服务组件数量少,依赖关系小。对于独立服务,过载管制次要针对操作系统、运行环境和应用程序[2,24,29]。对于简略的多层服务,服务入口点的网关监督整个零碎的负载状态,并在必要时回绝客户端申请,例如减载,以避免服务过载[5、7、23]。 然而,古代在线服务在架构和依赖性方面变得越来越简单,远远超出了传统过载管制的设计指标。古代在线服务通常采纳面向服务的架构(SOA)[12],该架构将传统的繁多服务体系结构划分为通过网络协议连贯的子服务。微服务架构,作为SOA的一种特殊化,通常由数百至数千个子服务(即微服务)组成,以反对简单的应用程序[9,21]。每个微服务在一台或多台机器上运行一组过程,并通过消息传递与其余微服务通信。通过拆散不同微服务的实现和部署,微服务体系结构促成了对每个微服务的独立开发和更新,而不论底层编程语言和框架。这就为简单的在线应用程序的跨团队开发提供了灵活性和生产力。 大型微服务零碎的过载管制必须思考零碎的复杂性和高动态性,这在理论利用中是十分具备挑战性的。首先,所有的微服务都必须被监控。如果任何微服务不在监控范畴内,则可能会在该地位呈现潜在的过载,并进一步波及到相干的上游微服务。因而,零碎可能会呈现级联过载,并最终挂起,导致受影响服务的高提早。然而,依附一些特定的微服务或机器仲裁来监督负载状态是极其艰难的,因为单个微服务或机器没有疾速倒退的部署视图。 其次,因为服务依赖关系的复杂性,让微服务独立地解决过载可能有问题。例如,假如解决客户端的申请须要依赖k个服务,然而这些服务以后都呈现过载并且都独立的以概率p来拒绝请求。这种状况下,实现客户端的申请的期望值是(1-p)K。如果p靠近1或者是k很大,零碎的吞吐量在这种状况下就趋于隐没。然而零碎过载并不会因为工作负载的削减而加重,因为失败申请曾经被解决的局部依然会耗费计算资源。这将导致系统进入一种难以避免的雪崩状态。 第三,过载管制须要适应服务变动、工作负载动静和外部环境。如果每个微服务都对其上游服务执行服务级别协定(SLA),那么它将极大地减慢这个微服务及其上游服务的更新进度,从而毁坏了微服务体系结构的次要劣势。相似地,如果微服务必须以合作形式替换大量的音讯来治理过载,它们可能无奈适应负载激增,因为过载管制音讯可能会因为零碎过载而被抛弃,甚至进一步好转零碎的过载情况。 为了应答上述挑战,咱们提出了一种用于大规模、面向帐户的微服务架构的过载管制计划,称为DAGOR。DAGOR的总体工作原理如下:当一个客户端申请达到入口服务时,它被调配了一个业务优先级和一个用户优先级,这样所有随后触发的微服务申请都会被强制在雷同的优先级上被统一地承受或回绝。每个微服务都为准入申请保护本人的优先级阈值,并通过查看零碎级资源指标,如待处理队列中申请的均匀等待时间,来监督本人的负载状态。如果检测到过载,那么微服务会应用自适应算法调整其负载削减阈值,该算法会尝试缩小一半的负载。同时,微服务还将阈值的变动告诉其间接的上游微服务,以便在微服务管道的晚期阶段能够回绝客户端申请。 DAGOR过载管制只应用了大量的阈值和微服务之间的边际协调。这种轻量级机制有助于进步过载解决的有效性和效率。DAGOR也是服务无感知的,因为它不须要任何特定服务的信息来进行过载管制。例如,尽管业务逻辑多种多样,但DAGOR曾经部署在微信的业务零碎中,以满足所有微服务的过载管制。此外,DAGOR对服务变更、工作负载动静和外部环境都具备自适应性,这使得它可能适应于疾速倒退的微服务零碎。 尽管网络门路中的减载问题在文献中曾经失去了宽泛的钻研[8,10,15],然而本文更侧重于如何为经营微服务零碎建设一个实用的过载管制解决方案。本文的次要奉献在于:(1)介绍了DAGOR的设计,(2)分享微信业务零碎中操作过载管制的教训,(3)通过试验验证DAGOR的性能。 本文残余的局部组织如下:第二节介绍了微信后端的整体服务架构以及它通常面临的工作负载动静。第三节形容微信微服务架构下的过载场景。第四节介绍了DAGOR过载管制的设计及其在微信中的利用。在第五节咱们进行试验以评估DAGOR,在第六节回顾相干工作并最初在第七节进行全文总结。 2. 背景作为背景,咱们介绍了微信后端的服务架构,该架构反对3000多种挪动服务,包含即时通讯,社交网络,挪动领取和第三方受权。 2.微信服务架构微信后端是基于微服务体系结构构建的,其中公共服务递归地组合成具备宽泛性能的简单服务。微信中不同服务之间的互相关系能够被建模为一个有向无环图(DAG),其中顶点示意服务,边示意两个服务之间的调用门路。具体来说,咱们将服务分为两大类:根底服务( basic service)和直达服务(leap service)。在服务DAG中,一个根底服务的出度(节点出边数)为0,而直达服务的出度为非0。换句话说,直达服务能够调用其余服务,如根底服务或者其余直达服务,来触发上游服务工作,而任何工作最终都会汇入到根底服务,不再进一步调用任何其余服务。特地地,在服务DAG中,入度边数为0的直达服务被称为入口服务。用户收回的任何服务申请的解决总是从一个入口服务开始,以一个根底服务完结。 图1展现了微信后端的微服务架构,该架构被分层为三层。数以百计的入口服务停留在顶层。所有的根本服务都搁置在底层。中间层蕴含除了入口服务以外的所有直达服务。每个服务工作都是以自顶向下的形式通过微服务体系结构来构建和解决的。特地地,所有根底服务被所有直达服务共享调用,并且都是服务于用户级目标1的最终服务。此外,中间层的直达服务由所有入口服务以及其余直达服务共享。大部分微信服务都属于这一层。 图1:微信微服务架构 对于微信来说,每天入口服务的申请总数通常为1010∼1011次。每个入口服务申请随后对合作微服务触发更多的申请,以实现用户冀望的行为。因而,微信后端基本上每秒钟须要解决数亿个服务申请,解决如此规模数据的零碎显然具备挑战性。 2.2 微信服务部署在微信业务零碎中,微信微服务零碎包容了超过3000个运行在20000台机器上的服务,并且随着微信的日益遍及,这些数字还在一直减少。该微服务架构容许不同的开发团队独立地部署和更新各自开发的服务。随着微信的一直倒退,微信的微服务零碎也在经验着服务更新的疾速迭代。例如,从2018年3月到5月,微信的微服务零碎均匀每天经验了近1000次的变更。依据咱们保护微信后端的教训,任何集中式或基于SLA的过载管制机制都很难反对如此大规模的疾速服务变更。 2.3 动静工作负载微信后盾解决的工作负载总是随工夫变动,并且不同状况下的稳定模式也有所不同。通常,顶峰工夫的申请量比日均匀申请量大3倍左右。在个别情况下,例如农历新年期间,高峰期的工作负载可能会高达日均匀工作负载的10倍左右。在服务申请量差距如此大的状况下,解决好这种动静工作负载是很有挑战性的。尽管适量配置的物理机器能够接受如此微小的工作负载稳定,但该解决方案显然是不经济的。相同地,通过认真设计过载管制机制,使其可能自适应地容忍零碎运行时的负载稳定,显得更加可取和理论。 3. 微信中的过载微服务架构中的零碎过载可能由多种起因造成的。其中最常见的包含:负载激增、服务协定变更导致的服务器容量升高、网络中断、系统配置扭转、软件缺陷和硬件故障。典型的过载场景包含过载的服务和相干调用门路上的服务申请。在本节中,咱们形容了三种根本的服务过载模式,它们是残缺的,并且可能用来形成其余简单模式的服务过载。图2展现了这三种根本模式,其中过载的服务由正告标记标记,沿调用门路关联的申请由箭头示意。 图2:常见的过载场景 3.1 过载场景在模式1中,如图2.a所示,过载产生在服务M。在微信业务零碎中,服务M通常是一种根底服务。这是因为在微服务架构中根底服务代表了服务DAG中的接管节点,因而它们是最沉闷的服务。在图2.a中,箭头示意一种通过服务A调用服务M的申请类型。当服务M过载时,发送到服务M的所有申请都会受到影响,从而导致响应提早甚至申请超时。更蹩脚的是,过载服务的上游服务(如服务A)也会受到影响,因为它们在期待过载服务的响应。这将导致过载从过载服务向其上游服务进行逆向流传。尽管模式1在SOA中很常见,但模式2和3是大规模微服务体系结构2所独有的。如图2.b所示,模式2相似于模式1,但波及从服务A到服务M的屡次调用。在一些业务逻辑中须要这样的屡次调用。例如,在加密/解密应用程序中,服务A首先能够调用服务M来解密某些数据,而后在本地操作明文数据,最初再次调用服务M来加密最终数据。咱们将相应的过载场景称为组合过载(subsequent overload),其正式定义如下:组合过载是指存在多个过载服务,或者单个过载服务被关联的上游服务屡次调用的过载场景。 在组合过载的场景中,上游服务发动的工作被胜利执行的条件是当且仅当其所有收回的申请都失去了胜利的响应。否则,如果发送到过载服务的任何服务申请未失去满足,则认为服务工作解决失败。显然,模式2(图2.b)和模式3(图2.c)都属于组合过载。模式2中的组合过载是因为对单个过载服务的间断调用,而模式3中的组合过载则是因为对不同过载服务的离开调用导致的。 组合过载减少了无效过载管制的挑战性。直观地讲,当服务过载时随机执行减载能够让零碎维持饱和的吞吐。然而,组合过载可能会出乎预料地大大降低零碎吞吐量。这是由调用过载服务的间断胜利服务束缚所导致的。例如,在图2.b所示的模式2中,假如服务A调用服务M两次,服务M配置为容量C,并且在服务过载时随机执行减载。咱们进一步假如服务M以后的工作负载为2C,而服务M仅由服务A调用。后果,服务M预计会回绝一半的申请,因而服务M单次调用的成功率为50%。从服务A的角度来看,其对服务M的调用成功率为50%×50%=25%。换句话说,服务A发送C个工作,2C的调用申请将被发送到服务M,然而服务A只有0.25C的申请被承受。相同,如果服务A的工作负载为0.5C,那么服务M只是饱和,没有过载,因而服务A工作的胜利数量为0.5C。由此能够看出,如果每个服务A工作不得不屡次调用服务M,那么组合过载会导致服务A的成功率非常低。同样的论点也实用于图2.c所示的模式3,惟一的区别就是服务A的成功率依赖于服务M和服务N的申请成功率的乘积。 在上述三种根本的服务过载模式中,模式1和模式2在微信业务零碎中占主导地位,而模式3绝对较少。为了无效地进行过载管制,咱们强调在运行工作负载很大时,必须正确处理组合过载,以维持零碎吞吐量。否则,在申请服务超载时,简略地采纳随机减载可能会导致客户端申请的成功率极低(例如靠近零)。这种“服务挂起”景象在咱们以前保护微信后端的实际中曾经被察看到,这促使咱们钻研适宜微信微服务架构的过载管制设计。 3.2 大规模过载管制的挑战与面向Web的三层架构和SOA的传统过载管制相比,微信微服务架构的过载管制存在两个独特的挑战。 首先,对于发送到微信后端的服务申请没有繁多的入口点。 这使得在全局入口点(如网关)处的集中式负载监控的传统办法生效。此外,一个申请能够通过简单的调用门路来调用多个服务。即便对于雷同类型的申请,相应的调用门路也可能齐全不同,这取决于特定于申请的数据和服务参数。因而,当某个特定的服务过载时,不可能准确地确定应该抛弃哪种申请来加重过载的状况。 其次,即便在分布式环境中采纳去中心化过载管制,过多的申请停止不仅会节约计算资源,还会因服务响应的高提早而影响用户体验。特地是,当组合过载产生时状况会变得重大。这就要求在申请类型、优先级、调用门路和服务属性方面进行某种协调,以正确地治理减载。然而,因为微服务体系结构中的服务DAG极其简单,并且在一直地演变,因而,保护老本以及与过载服务进行无效协调的零碎开销被认为过于低廉。 4. DAGOR 过载管制为微信微服务架构设计的过载管制计划称为DAGOR。其设计旨在满足以下要求: 服务无感知: DAGOR须要实用于微信微服务架构中的各种服务,包含外部和内部第三方服务。为此,DAGOR不应该依赖任何特定于服务的信息来执行过载管制。这种服务无感知的设计思考有两个长处:首先,过载管制机制具备高度可扩展性,以支持系统中大量的服务,同时适应服务部署的动态性。这对于一直倒退的微信业务至关重要,因为微信业务零碎中部署的各种服务常常更新,例如上线新服务、降级现有服务和调整服务配置等。其次,能够将过载管制的语义与服务的业务逻辑解耦。因而,服务配置不当并不影响过载管制的有效性。相同,过载检测能够帮忙发现导致服务运行时过载的暗藏配置缺点。这不仅有利于服务的开发和调试/调优,而且还进步了零碎的可用性和健壮性。独立但合作: 在微服务体系结构中,服务通常部署在一组物理机器上,以实现可伸缩性和容错。实际上,工作负载很难平衡地散布在这些机器上,并且每台机器的负载状态可能会呈现激烈且频繁的稳定,只有多数常见的模式在不同机器之间共享。因而,过载管制应该在单个机器的粒度上运行,而不是在全局范畴内。另一方面,机器间合作的过载管制对于解决组合过载也是必要的。不同机器之间的合作须要以服务为导向,以便上游服务的成功率能够与过载服务的响应率相匹配,只管组合过载会呈现。高效和偏心:当因为过载而不可避免地进行减载时,DAGOR应该可能维持最好的服务成功率。这意味着在失败的服务工作上所节约的计算资源(即CPU和i/O)被最小化。须要留神的是这些被立刻停止的工作所消耗的计算量很小,因而能够为其余有用的解决让出资源;相同,局部解决但最终被放弃的工作会使得在这些工作上所破费的计算被节约。因而,过载管制的高效是指该机制如何可能最小化在服务工作的局部解决上所耗费的计算资源。此外,当某个服务过载时,其上游服务也应该都可能维持大致相同的饱和吞吐量,而不论上游服务工作对过载服务进行了多少次调用。这反映了过载管制的公平性。4.1 过载检测DAGOR在服务器粒度上采纳去中心化的过载管制,因而每个服务器都会监督其负载状态,以便及时检测潜在的过载。对于针对单个服务器过载的监控,宽泛的性能指标曾经被现有的文献所钻研,包含吞吐量、提早、CPU利用率、包速率、期待申请数、申请解决工夫等[20, 25, 31]。DAGOR设计应用期待队列中申请的均匀等待时间(或排队工夫)来剖析服务器的负载状态。申请的排队工夫是由申请达到服务器与其在服务器上被启动解决之间的时间差来掂量的。 通过监控排队工夫来检测过载的理由初看起来并不显著。一个间接的问题是:为什么不思考应用响应工夫3来代替呢?咱们认为排队工夫比响应工夫更精确地反映负载状态。与排队工夫相比,响应工夫额定计算申请解决工夫。特地地,解决一个根底服务申请的工夫纯正由本地解决决定,而直达服务申请的解决工夫进一步波及解决上游服务申请的耗时。这导致了响应工夫沿服务调用门路被递归地测量,使得指标不能独自反映服务或服务器的负载状态。相同,排队工夫只受服务器本地解决能力的影响。当服务器因为资源耗尽而过载时,排队工夫与超额的工作负载成比例减少。另一方面,如果服务器有足够的资源来生产传入的申请,则排队工夫会放弃在一个较低的程度上。即便上游服务器可能响应速度较慢,只有上游服务器有足够的资源来解决期待的服务工作,其排队工夫也不会受到影响,只管其响应工夫的确会因为上游服务的响应迟缓而减少。换句话说,只有上游服务器的响应工夫减少,服务器的响应工夫就会减少,即便服务器自身并没有过载。这无力地证实了队列工夫能够反映服务器的理论负载状态,而响应工夫很容易呈现过载误报。 另一个问题是:为什么不应用CPU利用率作为过载批示?诚然,服务器中CPU利用率高表明服务器正处于高负载状态。然而,高负载并不一定意味着过载。只有服务器可能及时地解决申请(例如,排队工夫较短反映了这一点),即便其CPU利用率放弃较高,也不应该认为服务曾经过载。 DAGOR的负载监控是基于窗口的,并且窗口束缚由一个固定的工夫距离和该工夫距离内的一个最大申请数组成。在微信业务零碎中,只有满足任一个规范,每台服务器每秒或每隔2000次申请刷新一次均匀申请排队工夫的监控状态。这种复合束缚确保了在工作负载动静的状况下,监控能够立刻跟上负载的变动。对于过载检测,给定微信中每个服务工作的默认超时值为500ms,而示意服务器过载的均匀申请排队工夫阈值设置为20ms。这种教训配置曾经在微信业务零碎中利用了五年多,其有效性已被微信业务流动的零碎健壮性所证实。 4.2 服务准入管制一旦检测到过载,相应的过载管制就基于服务准入管制。DAGOR蕴含了一组服务准入控制策略。本文首先介绍了DAGOR过载管制中采纳的两种基于优先级的准入管制,而后扩大了该技术,以进一步反对自适应和协同的准入管制。 4.2.1面向业务的准入管制微信服务依据其业务意义和对用户体验的影响进行外部优先级排序,相应的服务申请也是如此。例如,登录申请具备最高的优先级,因为用户只有在胜利实现登录后能力与其余服务交互。另一个例子是,微信领取申请比即时消息申请具备更高的优先级。这是因为用户往往对其与金钱相干的交互(如挪动领取)比拟敏感,而他们通常可能承受消息传递服务中的肯定水平的提早或不一致性。微信的运行日志显示,当微信领取和即时消息服务呈现相似的服务不可用期时,用户对微信领取服务的投诉比对即时通讯服务的投诉高出100倍。相似的状况也实用于即时消息与朋友圈,因为用户冀望即时消息的内容传递比朋友圈更及时。 DAGOR中面向业务的准入管制是为每个用户申请调配一个业务优先级,并强制其所有后续申请继承雷同的业务优先级。当服务过载时,其减载策略将优先放弃低优先级申请,为高优先级申请让出资源。用户申请以及它在调用门路上的后续申请的业务优先级是由要在入口服务中执行的操作类型决定的。因为微信的微服务架构中存在着数百个入口服务,所以在入口服务中执行的不同操作的数量有数百个。业务优先级被事后定义并存储在哈希表中,该哈希表被复制到负责入口服务的所有微信后端服务器中。哈希表中的项记录了从操作ID(示意不同类型的操作)到优先级值的映射。图3展现了操作优先级哈希表的逻辑构造。留神,该哈希表并不蕴含所有类型的操作。默认状况下,哈希表中短少的操作类型对应于最低优先级。在哈希表中只记录那些无意排序的操作类型,优先级值越小,示意操作的优先级越高。这导致哈希表中只蕴含几十个条目。因为在入口服务中执行的优先级操作汇合在教训上是稳固的,所以只管微信业务疾速倒退,哈希表依然是紧凑的,很少有变动。 每当一个服务申请触发对上游服务的后续申请时,业务优先级值就会被复制到上游申请。通过递归,属于同一调用门路的服务申请共享雷同的业务优先级。这是基于这样的假如,即任何服务申请的胜利都依赖于它对上游服务的所有后续申请的联结胜利。因为业务优先级独立于任何服务的业务逻辑,因而基于业务优先级的DAGOR服务准入管制是服务无感知的。而且,上述面向业务的准入管制易于保护,特地是对于简单且高度动静的微服务架构(如微信后端)。一方面,通过引入操作优先级哈希表,业务优先级的调配在入口服务中实现,并且该哈希表很少随工夫变动4,这使得业务优先级调配策略绝对稳固。另一方面,微信的微服务架构的动静个别反映在根底服务和直达服务的变动上,而不是入口服务。因为变动频繁服务的申请的业务优先级是从上游服务申请继承而来的,因而这些服务的开发人员能够简略地将面向业务的准入管制性能作为黑盒来利用,而不用思考业务优先级5的设置。 图3:微信入口服务中执行的操作的业务优先级哈希表 4.2.2 面向用户的准入管制下面提到的面向业务的准入管制限度了是否抛弃申请取决于申请的业务优先级。换句话说,对于服务过载时的减载,面向业务的准入管制假设具备雷同业务优先级的申请要么全副被抛弃,要么全副被承受。然而在过载服务中,对雷同业务优先级的申请进行局部放弃有时是不可避免的。当过载服务的业务优先级的准入级别围绕其“现实最优性”稳定时,这种偶然性就会呈现。为了具体阐明,让咱们思考以下场景:过载服务中的减载齐全基于面向业务的准入管制。假如以后业务优先级的准入级别为,但服务依然过载。而后服务将准入级别调整为-1,即所有业务优先级值大于或等于的申请都被服务抛弃。然而,零碎很快就发现,应用这种准入级别使得服务处于低负载状态。后果,准入级别被设为,而后服务很快又会过载。上述情景将持续反复。后果,上述场景中,业务优先级等于的相干申请实际上被服务局部抛弃。 局部抛弃具备雷同业务优先级的申请可能会导致组合过载引发的问题。因为在这种状况下,这些申请实际上是被随机抛弃的。为了解决这一问题,咱们提出了面向用户的准入管制,作为对面向业务的准入管制的弥补。DAGOR中面向用户的准入管制是基于用户优先级的。准入服务通过一个以用户ID为参数的哈希函数动静生成用户优先级。每个准入服务每小时更改其哈希函数。因而,来自同一用户的申请可能会在一小时内被调配同一用户优先级,但在不同时间段调配不同的用户优先级。上述用户优先级生成策略具备双重的合理性。一方面,1小时周期的哈希函数交替容许用户在长时间段内取得绝对统一的服务质量。另一方面,哈希函数的交替思考了用户之间的公平性,因为高优先级在一天中的每个小时内被授予不同的用户。与业务优先级相似,用户优先级也绑定到属于同一调用门路的所有服务申请中。 面向用户的准入管制与面向业务的准入管制是互相协调的。对于业务优先级等于过载服务业务优先级准入级别的申请,相应的减载操作优先于用户优先级高的业务。一旦服务A对过载服务M的申请失去胜利的响应,服务A对服务M的后续申请也很有可能失去胜利的响应。这就解决了由模式2的组合过载引起的问题,如图2.b所示。此外,图2.c所示的模式3的组合过载也能够用相似的形式正确处理。假如上游服务A按顺序调用两个过载的依赖服务,即服务M和服务N。如果服务M的业务和用户优先级的准入级别比服务N的准入级别更严格,那么在模式3中的组合过载能够被打消。这是因为因为服务N宽松的准入级别,一个申请被服务M承受意味着其后续申请也被服务N承受。因为靠前的服务容易呈现更重大的过载,因而模式3中相干服务之间的这种准入级别的条件通常存在于微信业务零碎中。 4.2.3 面向会话的准入管制除了面向用户的准入管制之外,咱们还提出了面向会话的准入管制,以解决单纯利用面向业务的准入管制所带来的同样问题。面向会话的准入管制基于会话优先级,会话优先级的生成和性能与后面形容的用户优先级相似。惟一的区别是,生成会话优先级的哈希函数将会话ID作为参数。当用户胜利登录时,会向其调配一个会话ID,示意用户会话的开始。会话通常以用户执行确认登记完结。当同一用户在其先前登记后执行另一次登录时,将创立另一个具备不同会话ID的会话,从而会相应地生成一个新的会话优先级,只管哈希函数放弃不变。在DAGOR中的过载管制方面,面向会话的准入管制与面向用户的准入管制一样无效。但咱们在微信业务零碎中的操作教训表明,面向会话的许准入管制会升高用户体验。这是由微信用户在遇到应用程序服务不可用时,常常抉择登记并立刻从新登录的天然用户行为造成的。同样的景象也经常出现在其余挪动利用中。通过登记和立刻登录,用户将取得一个刷新的会话ID。因而,面向会话的准入管制为用户调配了一个新的会话优先级,该优先级可能足够高,以至于过载的服务后端承受他/她的服务申请。用户可能会逐步发现通过从新登录使他/她可能解脱服务不可用状态的“窍门”。当一个技巧被重复验证为无效时,它往往会成为用户习惯。然而,这种技巧并不能帮忙加重零碎后端上理论产生的服务过载。此外,因为呈现了误导性的登记和登录,会引入额定的用户申请,进一步好转过载的状况,最终影响了大多数用户的应用体验。相同,用户的即时从新登录不会影响面向用户的准入管制中他/她的用户优先级。因而,在DAGOR过载管制中,咱们更偏向于面向用户的准入管制,而不是面向会话的准入管制。 ...

September 10, 2021 · 1 min · jiezi

关于im:面对面小程序开源

开源地址: https://github.com/Tencent/Fa... 近期咱们公布了微信同声传译小程序插件,收费凋谢微信AI团队在机器翻译、智能语音畛域的业界当先成绩,使开发者简便地在小程序中退出机器翻译、智能语音能力。 当初咱们开源齐全基于微信同声传译插件实现的面对面翻译小程序,以进一步升高小程序开发者应用插件的门槛。 小程序开发者参考面对面翻译开源实现,只须要调用几个简略API,就能够实现一个翻译利用。 咱们的终极目标是:0门槛搞定!! 插件性能 语音输入语音合成文本翻译上面将展现如何应用插件“0门槛”5步轻松实现面对面翻译小程序。 step 1:增加插件 在应用前,须要登录官网 设置 → 第三方服务 → 增加插件 搜寻 【微信同声传译】并增加 在须要应用插件的小程序 app.json 中指明须要应用的插件版本等信息 // app.json{ ... "plugins": { ... "WechatSI": { "version": "0.0.6", "provider": "wx069ba97219f66d99" }}接下来,在index.js引入插件,获取全局惟一的语音辨认管理器recordRecoManager // index.jsconst plugin = requirePlugin("WechatSI")const manager = plugin.getRecordRecognitionManager()step 2:语音输入 心愿做到的成果是按住某个按钮,开始辨认语音,松开按钮就完结辨认 <!-- index.wxml --><view catchtouchstart="streamRecord" catchtouchend="endStreamRecord">中文</view>// index.jsPage({ data: {}, streamRecord: function() { manager.start({ lang: 'zh_CN', }) }, streamRecordEnd: function() { manager.stop() }})step 3:绑定录音回调事件 <!-- index.wxml --><!-- 能够在页面上实时输入语音辨认后果 --><view>语音辨认内容:{{currentText}}</view>// page.jsPage({ data: { currentText: '', }, initRecord: function() { //有新的辨认内容返回,则会调用此事件 manager.onRecognize = (res) => { let text = res.result this.setData({ currentText: text, }) } // 辨认完结事件 manager.onStop = (res) => { let text = res.result if(text == '') { // 用户没有谈话,能够做一下提醒解决... return } this.setData({ currentText: text, }) // 失去残缺辨认内容就能够去翻译了 this.translateTextAction() } }, translateTextAction: function() {}, onLoad: function() { this.initRecord() }})step 4:文本翻译 ...

September 10, 2021 · 2 min · jiezi

关于im:揭秘超分辨率的正确打开方式

写在前边:图像和视频通常蕴含着大量的视觉信息,且视觉信息自身具备直观高效的形容能力,所以随着信息技术的高速倒退,图像和视频的利用逐步遍布人类社会的各个领域。近些年来,在计算机图像处理,计算机视觉和机器学习等畛域中,来自工业界和学术界的许多学者和专家都继续关注着视频图像的超分辨率技术这个根底热点问题。本文试着讲述超分辨率技术的正确打开方式,浅谈视频图像的超分辨率技术的基本概念和利用场景等问题。 1.什么是超分辨率? 1.1 超分辨率初体验 简略来讲,图像超分辨率就是进步图像的空间分辨率,例如将一幅图片的分辨率由352x288扩充到704x576,不便用户在大尺寸的显示设施上观看。图像的超分辨率,是图像处理相干问题中的根底问题之一,并具备宽泛的理论需要和利用场景,在数字成像技术,视频编码通信技术,深空卫星遥感技术,指标辨认剖析技术和医学影像剖析技术等方面,视频图像超分辨率技术都可能应答显示设施分辨率大于图像源分辨率的问题。 简略来说超分辨率技术能够分为以下两种:1)只参考以后低分辨率图像,不依赖其余相干图像的超分辨率技术,称之为单幅图像的超分辨率(single image super resolution),也能够称之为图像插值(image interpolation)。 2)参考多幅图像或多个视频帧的超分辨率技术,称之为多帧视频/多图的超分辨率(multi-frame super resolution)。 这两类技术中,一般来讲后者相比于前者具备更多的可参考信息,并具备更好的高分辨率视频图像的重建品质,然而其更高的计算复杂度也限度了其利用。故,本文后边将以单图超分辨率/图像插值为例,进行超分辨率技术的介绍。 1.2 超分辨率实践形容 这个很直观的超分辨率问题,它的实践形容又是什么样子的呢?如图所示,超分辨率就是将左图中像素点之间的空间地位用像素点进行填充,使得整个图像具备更多的像素点,更丰盛的细节,从信号的角度讲就是补充出更多的高频成分。 通常在解决这个超分辨率问题的时候,咱们经常摸索这个进化信号是如何从咱们心愿的现实信号变动失去的(即分辨率的进化过程),如果对进化过程进行准确地形容,往往对其逆问题的求解有重要的意义。在本文的问题中,即超分辨率的进化模型,能够通过以下公式来形容: Y = HDX + n 其中Y为低分辨率的视频帧/图像,X为咱们现实高分辨率的视频帧/图像,而H和D别离为含糊算子和分辨率下采样算子,n为进化过程中产生的噪声。 由上述公式可知该进化问题存在着病构个性,即多个不同的高分辨率图像X,通过雷同的进化过程解决,能够失去同样的低分辨率图像Y。这就导致咱们无奈间接通过Y求解出一个准确的X,也是视频图像超分辨率问题始终是一个开放性问题的起因(逐步迫近合乎人眼视觉意识的解)。 依据图像超分辨率的技术路线进行分类,图像超分辨率技术大抵能够分为以下几类:基于定参数的线性滤波器技术,基于图像边缘构造的技术,基于图像重构束缚的技术和基于机器学习的技术。 2.什么时候用超分辨率? 先举一个小例子,一张悠久而经典的低分辨率老照片,怎么在一个先进的高清的显示器上播放?这就是低分辨率图片和高分辨率显示设施之间的不匹配。很显著,这个场景下咱们能够应用超分辨率技术,如下图所示。 单从图像的后处理显示的角度来讲,目前在PC和手机的屏幕显示性能上都配有相应的实时的超分辨率技术。通过观察可知,PC机上的超分辨率技术绝对比较简单(比方,邻近像素复制or双线性插值),而手机端屏幕的超分辨率技术比PC机显示的超分辨率技术的性能要更好一些,可能提供较好的主观视觉品质,且IOS零碎的手机的超分辨率技术相比于一些Andriod零碎手机的超分辨率技术性能更高一些。不同的超分辨率算法带来的加强视觉感触的成果不同,一些软件的超分辨率办法在带来更好的视觉品质的同时,也引入了很大的计算代价,一直挑战着显示设施的计算能力。 *3.超分辨率能节俭带宽吗?* 那么,前边赘述了这么多超分辨率的根底概念和应用办法,这个技术看起来就是万能的吗?有些人会有疑难,那就能够借着超分辨率技术用小分辨率的图进行通信就好了?其实并不是这样的! 在传输图片的时候,超分辨率和带宽有什么关系呢?一般来讲,当初的通信类利用中,图片都是须要通过压缩,传输,再解压缩这样的一系列过程。最间接的计划*A是依照原分辨率和现有带宽来进行压缩和传输,最终间接显示。而另一种计划B*是,先通过下采样的办法将原视频图像的分辨率下采为原分辨率的1/K,而后在低分辨率和现有带宽下进行压缩和传输,接收端在解码后通过超分辨率技术将该视频图像的分辨率以K倍重建后显示。如图所示 这里,超分辨率技术就不单单是一个视频图像的后处理技术,而是基于高低采样的编码传输框架中的一个重要环节。那么问题来了,这种下采样*-超分辨率的图片传输计划B可能节俭带宽吗?(最终图片的视觉品质统一的前提下),或者说是在雷同的带宽限度下,间接压缩传输大图片和压缩小图片再超分辨率显示,哪一种计划对显示的主观品质更好?*因为在这个场景下两个计划之间不能直观的从实践上比拟,所以咱们通过试验来进行阐明,设计了以下试验: 原图压缩计划*A,即原始高分辨率图像间接通过编码器进行压缩和传输,在解码端间接失去原始分辨率的重构图像。基于高低采样的图像压缩计划B*,即图像首先通过一个分辨率下采样(宽高均为1/2倍)的预处理办法,再将失去的低分辨率图像利用雷同的第三方的编解码器WebP进行压缩和传输,最初将在解码端失去的低分辨率图像利用超分辨率技术重建出其高分辨率的图片(这里超分辨率技术选用Google在G+上的计划和一种经典的深度网络的SCN办法)。 上面咱们给出两个不同策略下的图像压缩的(图片品质和文件大小)性能的比拟,如下图所示。 如图(a)和(b)两幅图像的性能比拟所示,图像纵坐标为图像全参考的视觉品质评估办法SSIM指标(用来比拟雷同分辨率下的原图和在对端最终显示的图像的差别),横坐标为图像经由第三方编码器WebP的压缩码流所占用的存储空间(KB),高低采样压缩曲线的四个数据点对应WebP品质因子别离为40,60,80,100,而原图压缩的四个数据点对应WebP品质因子别离是2,5,15,60。 试验中首先验证失去两个意识,一个是随着码率(带宽)的减少,间接压缩传输的计划A能疾速的达到近无损压缩或无损压缩。另一个是随着码率(带宽)的减少,超分辨率的计划B具备性能下限的限度,靠近下限时,减少码率就只会带来十分强劲视觉性能的晋升。 再通过试验曲线能够得出,在低码率范畴内,采纳原图压缩计划的压缩效率要低于基于采样的图像编码策略(即等同品质下,基于采样的图像编码策略图片文件更小,节俭带宽),而在中高码率范畴内,采纳原图压缩计划的压缩效率要优于基于采样的图像压缩计划(即等同品质下,超分辨率的图像编码策略的图片文件更大,节约带宽)。 进而咱们联合应用环境得出以下论断,在带宽重大受限的状况下,应用超分辨率技术可能改善其本来较差的视觉品质(即超分辨率技术在等同品质下节俭传输带宽);在带宽良好的状况下,原图分辨率间接压缩传输的计划可能提供更加好的视觉品质(即超分辨率技术在等同品质下节约传输带宽和后处理计算资源)。 目前,在常见的一些视频图像的利用中,咱们给定的码率均为中高码率以满足图像视频的视觉品质,大部分挪动终端上的视频图像利用的计划均为在指标分辨率上间接压缩,品质管制在高于WebP品质因子为60的程度,如试验中验证的一样,在这个码率范畴下,采纳现有的间接压缩原图计划A要优于下采样压缩低分辨率图像再做解压缩超分辨率的计划B。 3.小结 视频图像超分辨率技术,是图像处理相干问题中的根底问题之一,也是近些年来学术界钻研的热点问题。视频图像超分辨率技术作为图像的后处理技术能为了匹配更大分辨率的显示设施够晋升图像的主观视觉效果。在压缩传输的利用场景中,为了在等同带宽下取得更高的图像品质,超分辨率算法实用于低带宽时低质量图像上的加强,在带宽短缺时依然应该传输高分辨率图像,即下采样—超分辨率的技术,受限于其性能下限,仅仅在低码率传输条件下,采纳超分辨率加强的图像品质显著优于的在大图像上间接编码(即等同品质节俭带宽)。综上所述,视频图像超分辨率技术在利用中要思考计算复杂性限度,传输带宽的限度和视觉性能下限(主观视觉效果)等因素,来抉择失当的利用场景。 本文转自微信后盾团队,如有进犯,请分割咱们立刻删除 OpenIMgithub开源地址: https://github.com/OpenIMSDK/... OpenIM官网 : https://www.rentsoft.cn OpenIM官方论坛: https://forum.rentsoft.cn/ 更多技术文章: 开源OpenIM:高性能、可伸缩、易扩大的即时通讯架构 https://forum.rentsoft.cn/thr... 【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理 https://forum.rentsoft.cn/thr... 【OpenIM原创】开源OpenIM:轻量、高效、实时、牢靠、低成本的音讯模型 https://forum.rentsoft.cn/thr...

September 10, 2021 · 1 min · jiezi

关于im:实时移动通信中基于时空域联合约束的低照度视频增强技术

*视频通话是微信的根底性能之一,在理论利用中受光照条件及视频采集设施能力所限,视频发暗是影响主观体验的重要因素。咱们尝试改良这个问题,欢送留言交换 该项工作的次要成绩发表在ISCAS 2017国内会议上。("Low-LightingVideo Enhancement Using Constrained Spatial-Temporal Model for Real-Time MobileCommunication", ISCAS, pp:595-598, Baltimore, MD,USA, 2017) http://iscas2017.org/ 1.利用背景目前绝大多数智能手机具备了视频拍摄性能,但因为受镜头尺寸和老本的限度,采集的视频图像的单像素上的光通量较小。尤其室内场景光照有余或者低照度的状况下,局部手机因为曝光有余导致视频显著偏暗,限度了其实时的挪动视频通话的利用。低照度视频加强技术,是一种通过批改视频图像的像素值来无效的改善此类场景下的视频成果,晋升客户的主观感触的视频图像处理技术。通过该技术来补救低照度下手机拍摄的视频图像,能够扩充视频通话的利用场景,晋升用户的产品体验。2.相干技术现有的低照度视频图像增强技术次要借鉴低照度图像增强的一些办法,具体举几个例子:例如,直方图平衡(Hist Equalization):加强曲线为图像的概率累积散布函数,该办法能最大水平地拉伸整个图像的对比度。因为暗场景的图像其直方图存在顶峰,通过直方图平衡解决后,导致图像适度加强,从而使得图像失真,同时容易放大噪声。例如,对比度拉伸(Contrast Stretching):通过设计适合的映射曲线,管制全局各个灰阶加强幅度。但映射曲线不具备自适应性,对不同图像要设计专门的加强曲线,才能够达到加强图像的成果。Gamma校对是对比度拉伸的一种。例如,同态滤波(Homomorphic Filtering):是一种频域加强算法。像素值由光照重量和反射重量决定。其中光照重量位于低频段,反射重量位于高频段。将图像映射到频域后,将光照重量和反射重量在频域离开,再别离进行加强解决。该办法适宜光照不平均状况下的加强,如同时蕴含室内和室外场景。因而不适应于视频通话中的加强。其余的加强算法,如色调映射(Tone Mapping)和Retinex等办法,存在计算量过大或者容易在边缘处产生光晕等毛病,都不能间接用于实时视频加强的场合。3.设计动机在实时的挪动视频通话的利用条件下,咱们简要阐明现有技术的毛病及要解决的问题:(1)现有的视频加强计划次要是借鉴单幅图像的加强办法,因而只思考单帧信息,没有思考相邻帧之间的相关性。导致各帧间加强幅度不统一,从而呈现闪动或者颗粒景象,升高了主观成果。且对于亮度失常的图像,其加强算法往往过渡解决。(2)在实时视频聊天的场景中,对计算量及存储空间十分敏感。实用算法都必须在较小的计算量和存储需要,达到最佳的加强成果。而相似色调映射和Retinex的计算量过大,即使通过优化也无奈适应手机端的实时视频解决。通过剖析已有技术的技术特点和利用条件的限度因素,咱们心愿设计的算法具备以下几个特点:其一,加强低照度的视频图像。其二,间断的视频图像不产生闪动。其三,对亮度失常的图像不做夸大的再加强。其四,算法的计算复杂度可能满足实时挪动视频通话的限度。这样的设计思路,为后续的算法设计和试验验证提供了方向和规范。4.技术详述本文提出了一种实时挪动通信中基于时空域联结束缚的低照度视频加强技术。在该技术中咱们设计了图像空域的亮度加强束缚和对比度加强束缚,以及视频帧时域的亮度一致性束缚,并对提出的联结束缚框架给出了凸优化的闭合解。上面具体对每一个束缚的设计进行详尽介绍,最初给出问题的优化解。该办法在YUV420空间进行,将亮度重量Y和色度重量UV离开,只对Y重量进行解决,放弃UV色彩信息。图像灰度的取值范畴为[0-255]。首先,低照度视频图像增强的最重要的解决就是亮度加强。一种最为间接的形式就是应用一族加强函数来定义亮度值加强,如图1所示: 图1. 亮度值的加强函数族(横轴为低照度亮度值,纵轴为加强后的亮度值)。 在咱们的设计中,通过采集同一场景下低照度和失常照度的视频数据对,通过离线训练的形式,失去了基于训练样本的亮度加强函数族FI。 然而,因为单纯的晋升整体像素的亮度值,会使得图像整体的对比度不平衡,依然不能提供好的人眼主观视觉感触。咱们提出了自适应的视频图像亮度值域调整的算法,进而通过新的值域范畴来对图像进行直方图的均衡化调整。咱们统计图像的像素点的值域范畴时,排除掉最小的d%个像素和最大的d%个像素的烦扰,将两头范畴内的像素最大值和最小值进行调整,调整策略为自适应软阈值的办法。从而生成数据自适应的对比度加强函数FC。 只从繁多的图像维度来思考加强的问题,往往会产生相邻图像帧之间的亮度跳变,即闪动景象。为此咱们将以后帧和相邻多帧的均匀亮度的差别代价,结构出代价函数G,来束缚由亮度加强和对比度加强函数可能带来的闪动景象。 综上咱们设计的优化问题为: 易知三个束缚项均为二次项,问题能够通过最小二乘法求解,如下: 本文算法的创新性和奉献: (1)通过离线的办法训练亮度加强函数,用以正当的晋升亮度。依据以后低照度视频图像自适应的生成对比度加强函数,用以从新调整图像对比度。依据已解决帧的信息,自适应的调整邻近帧间的亮度一致性,克制闪动景象 (2)无效的将上述(1)的影响因素,对立成正则化的最优化框架下,来同时束缚满足上文前三点项设计要求(加强低照度的视频图像,间断的视频图像不产生闪动以及对亮度失常的图像不做夸大的再加强),并给出满足实时利用需要的求解形式。 (3)该算法具备较低的计算复杂度和极强的鲁棒性,试验证实其大量测试和线上的视频图像的加强成果中没有适度加强和失真加强的差品质样例。 5.试验后果咱们通过试验数据来验证咱们的办法的性能。首先咱们给出不同场景下不同暗图像增强算法的主观性能比拟。 图2. Bonsai图片上的主观试验后果,a示意原始暗视频图像,b-e别离示意文献13的办法,f示意咱们提出的办法解决的视频图像。 图3. Face图片上的主观试验后果,a示意原始暗视频图像,b-e别离示意文献13的办法,f示意咱们提出的办法解决的视频图像。 图2和图3别离给出了低照度条件下风物和人物的加强成果。从图中能够看出咱们的办法具备绝对较好的主观成果。 图4. Street视频上间断两帧的主观试验后果,a示意原始暗视频图像,b-e别离示意文献13的办法,f示意咱们提出的办法解决的视频图像。 图4给出了间断的视频帧中克制闪动成果的主观后果。如图能够看出一些办法存在着视频图像亮度闪动的景象,咱们的办法在加强亮度的同时不存在闪动的景象。 图5. Kimono视频图像的主观试验后果,a示意原始暗视频图像,b-e别离示意文献13的办法,f示意咱们提出的办法解决的视频图像。 图5给出了惯例亮度的视频帧,咱们的办法可能尽可能的不影响曾经足够亮堂的视频图像,防止了适度的加强。 进而咱们通过一系列的主观的数据来从另一个侧面评估咱们的算法。表1中,咱们通过将算法对立到Matlab平台上进行偏心的比拟,剖析各个算法的工夫复杂度,能够看出咱们的办法具备最好的实时性能,且在理论利用中该算法仅仅须要非常少的CPU计算代价,且具备良好的汇编优化成果,并不需要大规模的GPU等其余简单计算资源。 表2中,咱们通过利用无参考的品质评估NR-CDIQA办法,剖析各个算法的主观品质,能够看出咱们的办法具备最好的视觉性能。值得注意的是,在惯例亮度的视频图像Kimono中,咱们办法解决的得分最靠近于原视频图像的打分,即咱们没有夸大的适度加强。 参考文献[1] K. He, J. Sun, and X. Tang, “Single Image HazeRemoval Using Dark Channel Prior,” in Proc. IEEE Conf. Computer Vision and PatternRecognition., pp. 1956-1963, 2009. ...

September 8, 2021 · 1 min · jiezi

关于im:详解微信异步队列-MQ-20-的功能优化及拓展思路

背景介绍 MQ 1.0 公布之初,根本满足了个别业务场景的异步化需要,实现了单机下高性能的工作长久化和生产调度。1.0 的根本框架如下图所示: 能够看到,其次要分为 MQ 和 Worker 两局部。MQ 是工作的长久化和调度框架,Worker 是工作的解决框架。该组件与常见的队列相比,有几个特点: 关注单机性能,工作单机长久化,本机生产;框架染指了工作的整个生命周期,其中包含了:入队落盘、派发、解决、提交后果、销毁。业务基于框架开发,专一工作的解决逻辑。随着业务倒退,面对日益简单的业务场景,1.0 版本逐步显得力不从心。因而,在 1.0 的根底上,咱们实现了 MQ 2.0 版本,次要优化点包含以下几方面: 更优的任务调度更高效的工作解决更强的过载爱护上面对各个优化点具体解说。 更优的任务调度 现状剖析 IOS音讯告诉性能,是MQ组件的一个典型利用场景。微信的后盾具备多IDC散布的特点,不同IDC与苹果推送服务(APNs)之间的网络品质参差不齐,局部链路故障频发。 因为MQ 1.0 的工作只能本机生产,网络品质的降落将间接导致 Worker 生产能力的降落,进而产生积压,最终使音讯服务质量受损。 为此,咱们提出了跨机生产模式。其指标是实现一个去中心化、自适应的弹性生产网络,以解决零碎中呈现的部分积压问题。 任务调度是跨机生产的外围问题 生产模式从单机扩大到多机后,咱们要面临的外围问题是,哪些工作给哪个 Worker 去解决。其实,思考多机房、多IDC、带宽老本、工作延时等因素,咱们很容易失去一个直观而奢侈的思维: 工作优先在本机生产,产生积压时才产生跨机生产。 如何实现咱们想要的跨机生产呢?通过思考,咱们将问题合成为三个子问题: 拉工作还是推工作?Worker 如何感知 MQ 的积压?Worker 如何打消 MQ 的积压?上面逐个进行探讨。 拉工作还是推工作 MQ 1.0 下,MQ 能够精确察看到本机 Worker 的负载状态,并由其将工作推送给闲暇的 Worker 进行解决。推送的形式能够将工作的解决延时做到极低。 扩大到跨机生产后,Worker 能够生产任意 MQ 的工作。对 MQ 而言,曾经难以准确地保护全网每个 Worker 的状态了。若持续沿用推工作的形式,很可能会呈现 Worker 接管到超过其解决能力的任务量,从而产生积压。 若应用 Worker 拉取工作的形式,则拉取的速度能够依据 Worker 本身的生产能力调整,但在工作延时上,须要有所就义。 推工作:长处,低延时;毛病,工作在 Worker 端积压,无奈被从新调度;拉工作:长处,工作在 MQ 端积压,能够被闲暇的 Worker 拉走;毛病,延时稍高;通过简略的衡量,咱们选用了拉工作的形式,毕竟,咱们难以接受任务积压在 Worker 侧的状况。 ...

September 8, 2021 · 2 min · jiezi

关于im:TLS协议分析-九-现代加密通信协议设计

六. TLS协定给咱们的启发 — 古代加密通信协议设计在看了这么多的剖析和案例之后,咱们曾经能够演绎出加密通信协议设计的广泛问题,和常见设计决策, 设计决策点: 四类根底算法 加密/MAC/签名/密钥替换 如何抉择?对称加密目前毫无疑问应该间接用aead,最佳抉择就是 aes-128-gcm/aes-256-gcm/chacha20-poly1305了数字签名/验证计划,如果是挪动互联网,应该思考间接放弃 RSA,思考 P-256 的 ECDSA 公钥证书,或者更进一步的 ed25519 公钥证书。密钥替换算法,目前最佳抉择就是 curve25519,或者 P-256。对称加密算法+认证算法,如何抉择?或者间接用aead?签名算法如何抉择?RSA or ECDSA or Ed25519?思考未来的算法调整,要加版本号机制吗?倡议是加上,起码在密钥协商的步骤,要加上版本号。便于未来更新算法。RSA用作密钥替换是一个好的抉择吗?思考PFS倡议间接放弃RSA,RSA服务器端性能比ECDSA更差,签名更大费流量,而且没有前向安全性,给私钥保存带来更大危险。自建PKI,是个好的抉择吗?crl如何解决?自建PKI能够做到更平安,比方简略的客户端内置数字签名公钥。可是当须要紧急撤消一个证书的时候,只能通过紧急公布新版客户端来解决。必须用蹩脚的openssl吗?or something better?crypto++,botan, nacl/libsodium, polarssl?libsodium: ed25519+curve2519+chacha20+poly1305重放攻打如何解决?某种seq?或者nonce如何生成?握手过程被中间人篡改的问题怎么解决?性能:私钥运算的cpu耗费能够接受吗?加上某种cache? 要解决私钥运算的高cpu耗费,必然就须要 session ticket/session id 这种cache机制。显然session ticket 更好提早:密钥协商须要几个rtt?起码多少?加上cache后?和tcp比照如何TLS的性能(次要指服务器cpu耗费)还有空间能够压迫吗?我能设计一个性能更牛逼的吗?七. 附录:密码学根底概念本文曾经很长了,根底概念的内容更多,再开展介绍就太长了,上面就列一下点,贴一下参考资料,就先这样,当前再说吧。 当然,最好的材料是上面列的书。 1. 块加密算法 block cipherAES 等 《AES后分组明码的钻研现状 及发展趋势》http://www.ccf.org.cn/resourc... aead的介绍(作者是大神)https://www.imperialviolet.or... 3种组合形式之争http://www.thoughtcrime.org/b... CBC模式+MAC-then-encrypt的padding oracle 攻打, tls POODLE 破绽http://drops.wooyun.org/paper...https://defuse.ca/blog/recove... 128 bit 和 256 bit key size之争https://www.schneier.com/blog... nist 对 aes gcm 的技术标准,官网权威文档:http://csrc.nist.gov/groups/S... 一个gcm的调用范例https://github.com/facebook/c... DES1天之内破解DES(2008年)http://www.sciengines.com/com... iPhone 5S开始,A7芯片也有了aes硬件指令 (ARMv8 指令集),有825%的性能晋升:http://www.anandtech.com/show... 2. 流加密算法 stream cipherRC4,ChaCha20 等 ...

September 8, 2021 · 2 min · jiezi

关于im:TLS协议分析-八-实现与开源项目

三. TLS协定的代码实现 TLS的次要实现: OpenSSLboringssl(Google)libressls2n(Amazon)nss(Mozilla)polarsslbotangnutls(gpl)cyasslgo.cryptoopenssl 的 tls 协定实现有 6W 行,libressl 3.68W行, polarssl 1.29 W行, Botan 1.13 W行 openssl是其中代码最蹩脚的(没有之一)。openssl提供了的api都太过于底层,api设计的也很费解,而且重大匮乏文档。请参考 [《令人作呕的OpenSSL》] 链接 http://blog.csdn.net/dog250/a... 可怜的是,OpenSSL是用的最宽泛的,是事实上的规范。 boringsslGoogle’s OpenSSL fork by Adam Langley (@agl__) https://github.com/sweis/cryp... 四. TLS协定的部署与优化 这个方面网上的文章还是不少的,本文就简略一点。 全站https时代正在到来!,挪动互联网对人们生存的染指越来越深人,用户越来越多的隐衷数据和领取数据通过网络传输,人们的隐衷意识安全意识一直进步;运营商流量劫持,强行插入广告越来越引起反感。因而,各互联网大厂都开始切换到https。 例如,2015年3月百度全站切换到https,百度运维部的介绍文章:[《全站 https 时代的号角 : 大型网站的 https 实际系列》] 链接 http://op.baidu.com/2015/04/h... 。 不久后淘宝切了全站https,https://www.taobao.com/http://velocity.oreilly.com.c... 国外:由Snowden爆料,美国人发现NSA在大范畴深度地监听互联网; 还有openssl间断被爆多个重大安全漏洞。之后近2年,各种加密通信协议,软件,我的项目开始热门,各大厂商开始关注明码协定,做数据加密,信息安全。(openssl赞助,pfs被器重,) Google的性能数据: “In January this year (2010), Gmail switched to using HTTPS foreverything by default. .. In order to do this we had to deploy noadditional machines and no special hardware. On our productionfrontend machines, SSL accounts for < 1% of the CPU load, < 10 KB ofmemory per connection, and < 2% of network overhead… ...

September 8, 2021 · 2 min · jiezi

关于im:TLS协议分析-七-安全性分析

9. TLS协定的平安剖析平安剖析,重中之重,也是大家最关怀的。 平安剖析的第一步是建设攻打模型,TLS的攻打模式是: 攻击者有短缺的计算资源攻击者无奈失去私钥,无奈失去客户端和服务器内存外面的密钥等窃密信息攻击者能够抓包,批改包,删除包,重放包,篡改包。这个模型其实就是密码学外面个别假设的攻打模型。 好了,在这个模型下,TLS的安全性剖析如下: 9.1. 认证和密钥替换 的安全性TLS有三种认证模式:单方认证,服务器认证,无认证。只有蕴含了有服务器端认证,就能够免疫 man-in-the-middle 攻打。然而齐全匿名的会话是能够被 MITM 攻打的。匿名的服务器不能认证客户端。 密钥替换的目标,是产生一个只有通信单方晓得的共享密钥 pre_master_secret 。pre_master_secret 用来生成 master_secret 。 master_secret 用来生成 Finished 音讯,加密key,和MAC key。通过发送正确的Finished音讯,单方能够证实本人晓得正确的 pre_master_key。 9.1.1 匿名密钥替换匿名密钥替换是一种历史遗留的不平安形式。 匿名密钥替换缺失认证(Authentication),所以绝大多数场景下,咱们应该禁用这种形式。 9.1.2. RSA 密钥替换和认证当应用RSA的时候,合并了密钥替换 和 服务器端认证。RSA公钥蕴含在服务器证书中。要留神的是,一旦服务器证书的RSA私钥泄露,之前用该证书爱护的所有流量都会变成能够破解的,即没有前向安全性(Perfect Forward Secrecy)。须要前向安全性的TLS用户,应该应用 DHE 或者 EC TLS users desiring Perfect Forward Secrecy should use DHE 类的CcipherSuite。这样,如果私钥泄露,只须要更换私钥和证书就行,不会有更大的损失。 RSA密钥替换和认证的安全性基于,在验证了服务器的证书之后,客户端用服务器的公钥加密一个 pre_master_secret 。胜利地解密 pre_master_secret 并产生正确地 Finished 音讯之后,就能够确信服务器领有证书对应的私钥。 如果应用了客户端认证,通过 CertificateVerify 音讯来认证客户端。客户端会签订一个之前所有握手音讯的hash值,这些握手音讯包含 服务器的证书,ServerHello.random 。其中服务器证书确保客户端签订了和本服务器无关的绑定(即不能重放和别的服务器的握手),ServerHello.random 确保签名和以后握手流程绑定(即不能重放)。 9.1.3. Diffie-Hellman 密钥替换和认证当应用 DH 密钥替换的时候,服务器: 或者发送蕴含固定 DH参数的证书或者发送一组长期DH参数,并用 ECDSA/RSA/DSA 证书的私钥签订。而且在签订之前,长期DH参数和 hello.random 都参加hash计算,来确保攻击者不能重放老的签名值。无论如何,客户端都能够通过验证证书,或者验证签名,来确保收到的DH参数的确来自真正的服务器。 ...

September 7, 2021 · 5 min · jiezi

关于im:TLS协议分析-六-handshake协议扩展

5.11. handshake — Finished在 ChangeCipherSpec 音讯之后,应该立刻发送 Finished 音讯,来确认密钥替换和认证过程曾经胜利了。ChangeCipherSpec 必须在其它握手音讯和 Finished 音讯之间。 Finished 音讯是第一条用刚刚协商进去的参数爱护的音讯。接管方必须确认Finished音讯的内容是正确的。一旦某一方发送了,并且确认了对端发来的Finished音讯,就能够开始在连贯上发送和接管利用数据了。 音讯构造: struct { opaque verify_data[verify_data_length];} Finished;verify_data PRF(master_secret, finished_label,Hash(handshake_messages)) [0..verify_data_length-1];finished_label 对客户端发的Finished音讯来说,固定是字符串 "client finished". 对服务器发的Finished音讯来说,固定是字符串 "server finished".1.2.3.4.5.6.7.8.9.10.11.Hash示意握手音讯的hash。hash函数是前文 PRF 的hash 函数。或者 CipherSuite 规定的用于 Finished 计算的hash函数。 在TLS的之前版本中,verify_data 总是 12 字节。在TLS 1.2中,这取决于CipherSuite。如果CipherSuite没有显式规定 verify_data_length ,就当成12字节解决。未来的CipherSuite可能会规定别的长度,然而不能小于12字节。 Finished 音讯必须跟在 ChangeCipherSpec 音讯之后,如果程序错乱,就是 fatal error. handshake_message 的内容蕴含从 ClientHello开始,直到 本条Finished之前的所有音讯,只蕴含handshake层的音讯体,不蕴含record层的几个音讯头字段。包含CertificateVerify 音讯。同时,对客户端和服务器来说,handshake_message 的内容不同, 后发送者必须蕴含前发送者的 Finished 音讯。 留神:ChangeCipherSpec 音讯,alert,和其它的record 类型不是握手音讯,不蕴含在 hash计算中。同时,HelloRequest 音讯也不算在内。 5.12. handshake — NewSessionTicketSessionTicket 定义在 RFC5077 规范外面,2008年公布。 ...

September 7, 2021 · 2 min · jiezi

关于im:TLS协议分析-五-handshake协议-证书与密钥交换

5.4. handshake — Server Certificate当服务器确定了CipherSuite后,依据CipherSuite外面的认证算法,如果须要发送证书给客户端,那么就发送 Server Certificate音讯给客户端。Server Certificate总是在ServerHello之后立刻发送,所以在同一个RTT里。 Server Certificate外面蕴含了服务器的证书链。 音讯构造: opaque ASN.1Cert<1..2^24-1>;struct { ASN.1Cert certificate_list<0..2^24-1>;} Certificate;certificate_list: 证书列表,发送者的证书必须是第一个,后续的每一个证书都必须是前一个的签订证书。根证书能够省略 证书申请的时候,个别会收到好几个证书,有的须要本人依照这个格局来拼接成证书链。 如果服务器要认证客户端的身份,那么服务器会发送Certificate Request音讯,客户端应该也以 这条Server Certificate音讯的格局回复。 服务器发送的证书必须: 证书类型必须是 X.509v3。除非明确地协商成别的了(比拟少见,rfc里提到了例如 [OpenPGP格局] 链接 https://tools.ietf.org/html/r... )。服务器证书的公钥,必须和抉择的密钥替换算法配套。密钥替换+认证算法配套的证书中公钥类型RSA / RSA_PSKRSA 公钥;证书中必须容许私钥用于加密 (即如果应用了X509V3规定的key usage扩大, keyEncipherment比特位必须置位) 这种用法没有前向安全性,因而在 TLS 1.3中被废除了 DHE_RSA / ECDHE_RSARSA 公钥;证书中必须容许私钥用于签名(即如果应用了X509V3规定的key usage扩大, digitalSignature比特位必须置位),并且容许server key exchange音讯将要应用的签名模式(例如 PKCS1_V1.5 ,OAEP等)和hash算法(例如sha1, sha256等) DHE_DSSDSA 公钥; 历史遗留产物,素来没有被大规模用过,安全性差,废除状态。证书必须容许私钥用于签名,必须容许server key exchange音讯中应用的hash算法。DH_DSS / DH_RSADiffie-Hellman 公钥; 要求key usage外面的keyAgreement比特位必须置位。 这种用法没有前向安全性,因而在 TLS 1.3中被废除了 ECDH_ECDSA / ECDH_RSA能做 ECDH 用处的公钥;公钥必须应用 客户端反对的ec曲线和点格局。这种用法没有前向安全性,因而在 TLS 1.3中被废除了 ECDHE_ECDSAECDSA用处的公钥;证书必须运输私钥用作签名,必须容许server key exchange音讯外面要用到的hash算法。公钥必须应用客户端反对的ec曲线和点格局。“server_name” 和 “trusted_ca_keys” 扩大用于疏导证书抉择。其中有5种是ECC密钥替换算法:ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, ECDHE_RSA, ECDH_anon。ECC(椭圆曲线)体制相比RSA,因为公钥更小,性能更高,所以在挪动互联网环境下越发重要。以上ECC的5种算法都用ECDH来计算premaster secret, 仅仅是ECDH密钥的生命周期和认证算法不同。其中只有 ECDHE_ECDSA 和 ECDHE_RSA 是前向平安的。 ...

September 7, 2021 · 4 min · jiezi

关于im:TLS协议分析-四-handshake协议概览

5. handshake 协定handshake protocol重要而繁琐。 TLS 1.3对握手做了大批改,上面先讲TLS 1.2,讲完再介绍一下剖析TLS 1.3. 5.1.handshake的总体流程handshake protocol用于产生给record protocol应用的SecurityParameters。在handshake中: 客户端和服务器端协商TLS协定版本号和一个CipherSuite,认证对端的身份(可选,个别如https是客户端认证服务器端的身份),并且应用密钥协商算法生成共享的master secret。步骤如下: 替换Hello音讯,协商出算法,替换random值,查看session resumption.替换必要的密码学参数,来容许client和server协商出premaster secret。替换证书和密码学参数,让client和server做认证,证实本人的身份。从premaster secret和替换的random值 ,生成出master secret。把SecerityParameters提供被record层。容许client和server确认对端得出了雷同的SecurityParameters,并且握手过程的数据没有被攻击者篡改。Handshake的后果是在单方建设雷同的Session,Session 蕴含下列字段: session identifiersession id,用来惟一标识一个session,在session 复原的时候,也要用到peer certificate对端的 X509v3 格局证书. 如果不须要认证对端的身份,就为空。compression method压缩算法,个别被禁用cipher specCipherSuite,如上文介绍,蕴含: 用于生成key的pseudorandom function (PRF) , 块加密算法例如AES, MAC算法 (例如 HMAC-SHA256). 还包含一个 mac_length字段,在后文的we握手协定介绍master secret48字节的,client和server共享密钥。is resumable一个标记位,用来标识以后session是否能被复原。以上字段,随后被用于生成 record层的SecurityParameters,多个连贯能够通过握手协定的session复原性能来复用同一个session。 握手协定应用 非对称加密/密钥协商/数字签名 3类算法,因而要求读者对这3类算法概念清晰,能精确辨别。在此廓清一下,:非对称的算法分为3类:, 非对称加密,有:RSAES-PKCS1-v1_5,RSAES-OAEP ,Rabin-Williams-OAEP, Rabin-Williams-PKCS1-v1_5等非对称密钥协商,有:DH,DHE,ECDH,ECDHE 等非对称数字签名:RSASSA-PKCS1-v1_5,RSASSA-PSS,ECDSA,DSA,ED25519 等另外,非对称加密算法,能够当作密钥协商算法来用,所以 RSAES-PKCS1-v1_5,RSAES-OAEP 也能够当作密钥协商算法来用。 插播一段 RSA: RSA的理论工程利用,要遵循PKCS#1 规范,见 https://www.ietf.org/rfc/rfc3447 其中的 RSAES-PKCS1-v1_5 和 RSASSA-PKCS1-v1_5 是应用RSA算法的两种不同scheme(体制)。RSAES示意 RSA Encryption schemes,即非对称加密,RSAES有:RSAES-OAEP,RSAES-PKCS1-v1_5两种,其中RSAES-OAEP更新更平安 RSASSA示意 Signature schemes with appendix,即appendix模式(appendix和recovery的区别请参看密码学教材)的非对称数字签名算法。RSASSA有: RSASSA-PSS, RSASSA-PKCS1-v1_5 两种, 其中RSASSA-PSS更新更平安 ...

September 7, 2021 · 3 min · jiezi

关于im:TLS协议分析-一-设计目标及历史

最近发现密码学很有意思,刚好还和工作有点关系,就钻研了一下,本文是其中一部分笔记和一些思考。 密码学实践艰深,概念繁多,自己常识程度无限,谬误不免,如果您发现错误,请务必指出,非常感谢! 本文指标: 学习鉴赏TLS协定的设计,透彻了解原理和重点细节跟进一下密码学应用领域的历史和停顿整顿古代加密通信协议设计的个别思路本文有门槛,读者须要对古代密码学有清晰而零碎的了解,本文最初的参考文献里有一些很不错的学习材料。 目录 : TLS协定剖析 与 古代加密通信协议设计一 . TLS协定的设计指标:1. 密码学的方法论2. TLS的设计指标3. TLS的历史二. TLS协定的原理1. 自顶向下,分层形象2. TLS CipherSuite3. 协定分层4. record 协定4.1. SecurityParameters4.2. record层分段4.3. record层的密码学爱护4.4. record层的密码学爱护--MAC4.5. record层的密码学爱护--stream cipher4.6. record层的密码学爱护-- CBC block cipher4.7. record层的密码学爱护-- AEAD cipher4.8. record层的密码学爱护-- Key扩大5. handshake 协定5.1.handshake的总体流程5.2. handshake 协定外层构造5.3. handshake -- ClientHello,ServerHello,HelloRequest5.4. handshake -- Server Certificate5.5. handshake -- Server Key Exchange5.6. handshake -- Certificate Request5.7. handshake -- Server Hello Done5.8. handshake -- Client Certificate5.9. handshake -- Client Key Exchange5.9.1. RSA 加密的 Premaster Secret 音讯5.9.2. 客户端 Diffie-Hellman 公钥5.9.3 客户端 EC Diffie-Hellman 公钥5.10. handshake -- Cerificate Verify5.11. handshake -- Finished5.12. handshake -- NewSessionTicket6. ChangeCipherSpec 协定7. Alert 协定8. application data协定9. TLS协定的平安剖析9.1. 认证和密钥替换 的安全性9.2. 版本回退攻打9.3. 针对握手过程的攻打9.4. 针对 Resuming Sessions 的攻打9.5. 针对利用数据保护的攻打9.6. 显式 IV的安全性9.7. 加密和MAC组合模式的安全性9.8. DOS 攻打下的安全性9.9.Session Ticket 的平安剖析10. TLS扩大:11. TLS的配套:PKI体系11.1. X.509 证书11.2.现有PKI体系暴露出的问题11. TLS协定历史上呈现过的破绽,密码学常见陷阱11.1. TLS的破绽12.1. TLS的破绽12.2. 密码学常见陷阱13. 下一代TLS: TLS 1.3三. TLS协定的代码实现四. TLS协定的部署与优化五. 更多的加密通信协议case:QUIC,iMessage,TextSecure, otr, ios HomeKit,libsodium1. QUIC2. apple ios iMessage3. apple ios HomeKit4. TextSecure5. otr 协定6. libsodium/NaCL 等六. TLS协定给咱们的启发 -- 古代加密通信协议设计七. 附录:密码学根底概念八. 参考文献:1. TLS/SSL 相干RFC及规范2. 协定剖析文章3. 理论部署调优相干4. 密码学相干5. 相干开源我的项目一 . TLS协定的设计指标:1. 密码学的方法论密码学和软件开发不同,软件开发是工程,是手艺,造轮子是写代码的一大乐趣。软件开发中经常有各种衡量,个别难有明确的对错,个别还用修建来比较软件的构造,设计的优雅被高度重视。 ...

September 6, 2021 · 2 min · jiezi

关于im:100亿次的挑战如何实现一个有把握的春晚摇一摇系统

这是2015年年初(羊年春晚)摇一摇流动的技术复盘文章。在数年之后再次复习,有很多架构上的取舍依然能够给相似的流动参考,因而从新收回来。羊年春晚摇一摇流动曾经落下帷幕,当初回过头来看看这一全民参加的乏味的流动背地,有着怎么的后盾零碎?这个零碎又是如何被设计与实现进去的? 春晚摇一摇流动 在理解这个零碎之前,先看看羊年春晚有哪些流动模式?春晚摇一摇复用了摇一摇入口,但提供了全新的界面和交互内容。 在羊年春晚摇一摇界面里,用户摇动手机后,能够看到明星拜年、全家福、好友贺卡等精彩纷呈的流动页;也会有舒适的“劳动一下”,或让很多误以为中奖的“挂服务器”等非凡用处的页面。 大家最期待的必定是摇红包,摇中红包的侥幸用户除了本人领到一份红包(种子红包)外,还能够领到若干份用于分享给其余好友的红包(决裂红包)。 围绕这些流动,上面将会通过4个处于我的项目不同阶段的里程碑版本来介绍咱们设计、实现这一零碎过程中的一些思考和做法,特地是题目里提到的“有把握”是由何而来。 V0.1原型零碎 原型零碎很简略,但曾经根本实现了春晚摇一摇的需要。原型零碎的架构见下图。 相干的解决流程如下: 用户摇动手机后,客户端产生摇一摇申请,申请发到接入服务后,会被转发到摇一摇服务;摇一摇服务会依据现场节目的流程,通过一系列的逻辑判断,给客户端返回一个后果:明星拜年、红包或者其余流动;假如是摇到了红包,因为红包都是企业资助的,须要对企业形象进行展现,客户端会从CDN拉回这个企业的LOGO等资源,最终展现出一个残缺的红包;随后用户拆红包时,申请会进入红包零碎,再到领取零碎,最初到财付通零碎实现一系列简单的账务解决,最终拿到红包;用户还能够分享红包,被分享的红包通过音讯零碎发给好友或群,其他人能够再抢一轮;在这一过程中,平安零碎保障红包流动的业务平安。上述数据的流动能够分下类:资源流、信息流、业务流和资金流。本文将次要聚焦在资源流和信息流。 面临的挑战 原型零碎看起来曾经足够简略,性能也根本齐备,是不是能够稍加批改后间接用在春晚现场呢?答案必定是不行。那么问题来了:为什么不行? 答复这一问题前,咱们先看一下看似简略的流动背地,面临着哪些挑战? 海量用户申请,预计申请峰值1000万/秒 **** 1000万/秒到底是多大的规模,能够通过下图更直观地感触下: 注:抢火车票数据援用自公开数据 春晚全程互动,不确定因素多 这个零碎须要跟羊年春晚全程严密互动,从我的项目开始到完结,有一系列的不确定因素会加大零碎实现的复杂度:在开发阶段,针对节目与流动模式如何配合这个问题的探讨有可能继续到春晚前,如何使零碎能服务多变的需要?在春晚现场,节目数量多,节目时长甚至程序都有可能调整,如何做到现场节目与摇一摇流动无缝连接? 零碎深度定制,成败在此一举 作为专为春晚设计的零碎,部署上线后真正能运行的工夫就只有几个小时,这几个小时内,惯例零碎所提倡的灰度公布、先扛住再优化等做法并不是太实用。在这短暂的工夫内,只有一次机会:要么胜利,要么失败。 全民高度关注,必须胜利 春晚会有7亿左右的观众,大家对这一流动抱有很大冀望,全民注目之下,只能胜利,不能失败。 短少历史教训,把握不大 如此大型的流动,对咱们而言是前所未有的,并没有太大的信念。前边提到的1000万/秒的峰值是如何估算进去?各个环节会有多少用户参加?零碎须要预留多少资源?这些问题不会有现成的答案,都须要摸索与思考。 可见,在看似简略的流动背地,暗藏了微小的挑战,之前假如的原型零碎不太可能胜任,须要做更深刻的优化。 须要优化哪些环节?比拟不言而喻的有三个: 流量带宽 春晚摇一摇须要用到大量的多媒体资源,这些资源都须要从CDN下载。通过评估,带宽峰值需要是3Tb/s,会带来微小的带宽压力。即便咱们有有限的资源,带宽需要能被满足,客户端在摇一摇后下载资源所需的等待时间也会带来很大的用户体验侵害,是不可承受的。 接入品质 **** 接入是后盾零碎的第一道关,所有申请都会达到接入。预计当晚会有3.5亿的在线,如何尽可能保障外网接入品质?甚至在外网稳定时也不受太大影响? 海量申请 1000万/秒的申请从外网涌进来后,都被路由给摇一摇服务,也就是说摇一摇服务也将有1000万/秒的申请量。这意味着须要确保零碎内2个1000万/秒的高可用,在分布式系统内,这是个挺大的问题。 如果要对系统是否最终取得成功量化一个信念指数的话,这个原型零碎的信念指数是10。这个数字示意如果春晚摇一摇采纳这套零碎并取得成功,咱们认为90%是靠运气。也能够换种说法:拿这个零碎到春晚摇一摇,90%的可能会挂掉。 零碎必定不能以运气为根底,这几个问题如何解决? V0.5 测试版V0.5的指标就是为了解决V0.1原型零碎里的几个问题。 资源预下载春晚应用的资源比拟多,也比拟大,但根本都是动态资源,是能够提前几天下载到客户端的。保留到本地后,在须要应用的时候,客户端间接从本地加载,从而省去了集中在线下载所需的带宽需要,另外用户摇一摇时不再须要下载资源,能够有更好的用户体验。下图展现了资源预下载过程。 资源推送模块负责将资源上传到CDN,同时推送资源列表给客户端。推送过程基于微信音讯零碎实现,能够在极短时间内把资源列表推送给几亿的用户。 资源预下载须要解决以下几个问题: 资源交付状况资源更新资源下载失败资源覆盖率离线资源平安通过这套资源预下载零碎,2015.2.9 - 2015.2.18 期间,下发了资源65个,累计流量3.7PB,其中闲时峰值达到1Tb/s。 外网接入梳理要保障接入品质,除了须要保障接入服务自身的稳定性外,须要做到: 具备在某些外网接入呈现稳定的时候,能主动切换到失常接入服务的能力;保障网络与服务具备足够的冗余容量。微信客户端曾经具备了外网主动容灾切换的能力,下边再看一下零碎的外网部署状况。 咱们从新梳理了外网的部署,最终在上海IDC和深圳IDC各设置了9个TGW接入集群。每个IDC都在3个不同的园区别离部署了电信、挪动和联通的外网接入线路。 另外,接入服务也进行了长期裁减,两地共有638台接入服务器,最多反对14.6亿的同时在线。 接入服务内置“摇一摇”架构变动 后面提到,零碎须要面对预计1000万/秒从外网的申请,同时还须要在内网转发同样是1000万/秒的申请给摇一摇服务,除此之外,还须要在各种异常情况下确保高可用。在如此海量申请之下,在这个分布式系统中,任何一点网络或服务的稳定都可能是灾难性的,这里边的艰难水平可想而知。 侧面解决这一问题的老本过高,咱们抉择了去掉摇一摇服务——把摇一摇逻辑集成到了接入服务,从而去掉了1000万/秒的转发申请。 但这样做,有一个前提:不能升高接入服务的稳定性。因为不单是春晚摇一摇申请,微信音讯收发等根底性能的申请也须要通过接入服务来直达,如果嵌入的摇一摇逻辑把接入服务拖垮,将得失相当。 接入服务的架构刚好有助于解决这个问题。 如上图所示,接入服务有一个网络IO模块,这个模块保护了来自客户端的TCP连贯,收发数据,负责跟客户端通信。网络IO模块是作为独立的过程组运作的,收到的申请通过本机共享内存发给接入逻辑模块解决。接入逻辑模块也是一组独立运行的过程,通常状况下是由申请直达逻辑通过RPC把申请转发给其余逻辑服务器解决。当初摇一摇逻辑作为嵌入逻辑,整合到了接入逻辑模块。因为网络IO模块与接入逻辑模块互相隔离,能够独自对接入逻辑模块进行降级,不会影响到已有的网络连接,这大大降低了嵌入逻辑带来的危险。 但这样还不够,还能够把嵌入到接入逻辑模块里的摇一摇逻辑尽可能简化,只保留比较简单、稳固、只须要单机计算即可实现的轻量逻辑;把其余较简单、可能须要常常变更、或须要跨机拜访的逻辑独立为摇一摇agent,作为独立运行的过程,通过本机共享内存与嵌入摇一摇逻辑通信。 摇一摇逻辑实现 接入服务架构的批改使得内置摇一摇逻辑变得可能,剩下的就是怎么实现春晚摇一摇逻辑?春晚摇一摇逻辑最重要的是摇红包,摇红包则须要重点解决以下问题: 红包如何发放? ...

September 6, 2021 · 1 min · jiezi

关于im:微信PaxosStore深入浅出Paxos算法协议

“与其预测将来,不如限度将来”,这应该是Paxos协定的核心思想。Paxos协定自身是比较简单的,如何将Paxos协定工程化,才是真正的难题。这是来自微信工程师的教训,以供参考。 引言 早在1990年,Leslie Lamport(即 LaTeX 中的"La",微软研究院科学家,取得2013年图灵奖)向ACM Transactions on Computer Systems (TOCS)提交了对于Paxos算法的论文The Part-Time Parliament。几位审阅人示意,尽管论文没什么特地的用途,但还是有点意思,只是要把Paxos相干的故事背景全副删掉。Leslie Lamport心高气傲,感觉审阅人没有丝毫的幽默感,于是撤回文章不再发表。 直到1998年,用户开始反对Paxos,Leslie Lamport从新发表文章,但相比1990年的版本,文章没有太大的批改,所以还是不好了解。于是在2001年,为了通俗性,Leslie Lamport简化文章发表了Paxos Made Simple,这次文中没有一个公式。 但事实如何?大家无妨读一读Paxos Made Simple。Leslie Lamport在文中渐进式地、从零开始推导出了Paxos协定,两头用数学归纳法进行了证实。可能是因为表述程序的问题,导致这篇文章仿佛还是不好了解。 于是,基于此背景,本文依据Paxos Made Simple,从新形容Paxos协定,提供两种证实办法,给出常见的了解误区。冀望读者通过浏览本文,再联合Paxos Made Simple,就能够深刻了解根本的Paxos协定实践。 基本概念 Proposal Value:提议的值;Proposal Number:提议编号,要求提议编号不能抵触;Proposal:提议 = 提议的值 + 提议编号;Proposer:提议发起者;Acceptor:提议接受者;Learner:提议学习者。留神,提议跟提议的值是有区别的,前面会具体阐明。协定中Proposer有两个行为,一个是向Acceptor发Prepare申请,另一个是向Acceptor发Accept申请;Acceptor则依据协定规定,对Proposer的申请作出应答;最初Learner能够依据Acceptor的状态,学习最终被确定的值。 不便探讨,在本文中,记{n,v}为提议编号为n,提议的值为v的提议,记(m,{n,v})为承诺了Prepare(m)申请,并承受了提议{n,v}。 协定过程 第一阶段A Proposer抉择一个提议编号n,向所有的Acceptor播送Prepare(n)申请。 第一阶段B Acceptor接管到Prepare(n)申请,若提议编号n比之前接管的Prepare申请都要大,则承诺将不会接管提议编号比n小的提议,并且带上之前Accept的提议中编号小于n的最大的提议,否则不予理睬。 第二阶段A Proposer失去了少数Acceptor的承诺后,如果没有发现有一个Acceptor承受过一个值,那么向所有的Acceptor发动本人的值和提议编号n,否则,从所有承受过的值中抉择对应的提议编号最大的,作为提议的值,提议编号依然为n。 第二阶段B Acceptor接管到提议后,如果该提议编号不违反本人做过的承诺,则承受该提议。 须要留神的是,Proposer收回Prepare(n)申请后,失去多数派的应答,而后能够轻易再抉择一个多数派播送Accept申请,而不肯定要将Accept申请发给有应答的Acceptor,这是常见的Paxos了解误区。 小结 下面的图例中,P1播送了Prepare申请,然而给A3的失落,不过A1、A2胜利返回了,即该Prepare申请失去多数派的应答,而后它能够播送Accept申请,然而给A1的丢了,不过A2,A3胜利承受了这个提议。因为这个提议被多数派(A2,A3造成多数派)承受,咱们称被多数派承受的提议对应的值被Chosen。 三个Acceptor之前都没有承受过Accept申请,所以不必返回承受过的提议,然而如果承受过提议,则依据第一阶段B,要带上之前Accept的提议中编号小于n的最大的提议。 Proposer播送Prepare申请之后,收到了A1和A2的应答,应答中携带了它们之前承受过的{n1, v1}和{n2, v2},Proposer则依据n1,n2的大小关系,抉择较大的那个提议对应的值,比方n1x > n2,那么就抉择v1作为提议的值,最初它向Acceptor播送提议{n, v1}。 Paxos协定最终解决什么问题? 当一个提议被多数派承受后,这个提议对应的值被Chosen(选定),一旦有一个值被Chosen,那么只有依照协定的规定持续交互,后续被Chosen的值都是同一个值,也就是这个Chosen值的一致性问题。 协定证实 上文就是根本Paxos协定的全部内容,其实是一个十分确定的数学问题。上面用数学语言表达,进而用谨严的数学语言加以证实。 Paxos原命题 ...

September 6, 2021 · 1 min · jiezi

关于im:PhxSQL设计与实现

https://github.com/tencent-we... *PhxSQL是一个兼容MySQL、服务高可用、数据强统一的关系型数据库集群。PhxSQL以单Master多Slave形式部署,在集群内超过一半机器存活的状况下,可本身实现主动Master切换,且保证数据一致性。* 相比目前业界风行的MySQL高可用计划,PhxSQL有三个劣势: 不少MySQL高可用计划只实现了高可用,不保证数据强统一;PhxSQL完满地同时满足了高可用和强统一;在主备数据一致性上,PhxSQL达到了和zookeeper同样的级别;PhxSQL的高可用计划不依赖zookeeper这类第三方选主服务,比照其余的高可用计划在部署上更加简略;齐全兼容MySQL,已有的MySQL应用程序齐全不须要做任何的批改就能迁徙到PhxSQL。本文以PPT的模式来论述一下PhxSQL的设计与实现。从MySQL的容灾缺点开始讲起,接着论述实现高可用强统一计划的思路,而后具体分析每个实现环节要留神的要点和解决方案,最初展现了PhxSQL在容灾和性能上的成绩。 本文原创作者微信团队转自微信后盾团队如有侵权请分割咱们删除 OpenIMgithub开源地址: https://github.com/OpenIMSDK/... OpenIM官网 :https://www.rentsoft.cn OpenIM官方论坛:https://forum.rentsoft.cn/ 更多技术文章: ...

September 3, 2021 · 1 min · jiezi

关于im:微信开源libco简单易用高性能的协程库

libco是微信后盾大规模应用的c/c++协程库,2013年至今稳固运行在微信后盾的数万台机器上。libco在2013年的时候作为腾讯六大开源我的项目首次开源,咱们最近做了一次较大的更新,同步更新在https://github.com/tencent/libco(点击浏览原文间接拜访)上。libco反对后盾麻利的同步格调编程模式,同时提供零碎的高并发能力。 libco反对的个性 ❏ 反对CGI框架,轻松构建web服务(New); ❏ 反对gethostbyname、mysqlclient、ssl等罕用第三库(New); ❏ 可选的共享栈模式,单机轻松接入千万连贯(New); ❏ 欠缺简洁的协程编程接口: ▪ 类pthread接口设计,通过co_create、co_resume等简略清晰接口即可实现协程的创立与复原; ▪ 类__thread的协程公有变量、协程间通信的协程信号量co_signal (New); ▪ 非语言级别的lambda实现,联合协程原地编写并执行后盾异步工作 (New); ▪ 基于epoll/kqueue实现的小而轻的网络框架,基于工夫轮盘实现的高性能定时器; libco产生的背景 晚期微信后盾因为业务需要复杂多变、产品要求疾速迭代等需要,大部分模块都采纳了半同步半异步模型。接入层为异步模型,业务逻辑层则是同步的多过程或多线程模型,业务逻辑的并发能力只有几十到几百。随着微信业务的增长,零碎规模变得越来越宏大,每个模块很容易受到后端服务/网络抖动的影响。 异步化革新的抉择 为了晋升微信后盾的并发能力,个别的做法是把现网的所有服务改成异步模型。这种做法工程量微小,从框架到业务逻辑代码均须要做一次彻底的革新,耗时耗力而且危险微小。于是咱们开始思考应用协程。 ❏ 但应用协程会面临以下挑战: \1. 业界协程在c/c++环境下没有大规模利用的教训; \2. 如何管制协程调度; \3. 如何解决同步格调的API调用,如Socket、mysqlclient等; \4. 如何解决已有全局变量、线程公有变量的应用; 最终咱们通过libco解决了上述的所有问题,实现了对业务逻辑非侵入的异步化革新。咱们应用libco对微信后台上百个模块进行了协程异步化革新,革新过程中业务逻辑代码根本无批改。至今,微信后盾绝大部分服务都已是多过程或多线程协程模型,并发能力相比之前有了质的晋升,而libco也成为了微信后盾框架的基石。 libco框架 同步格调API的解决 对于同步格调的API,次要是同步的网络调用,libco的首要任务是打消这些期待对资源的占用,进步零碎的并发性能。一个惯例的网络后盾服务,咱们可能会经验connect、write、read等步骤,实现一次残缺的网络交互。当同步的调用这些API的时候,整个线程会因为期待网络交互而挂起。 尽管同步编程格调的并发性能并不好,然而它具备代码逻辑清晰、易于编写的长处,并可反对业务疾速迭代麻利开发。为了持续放弃同步编程的长处,并且不需批改线上已有的业务逻辑代码,libco翻新地接管了网络调用接口(Hook),把协程的让出与复原作为异步网络IO中的一次事件注册与回调。当业务解决遇到同步网络申请的时候,libco层会把本次网络申请注册为异步事件,本协程让出CPU占用,CPU交给其它协程执行。libco会在网络事件产生或者超时的时候,主动的复原协程执行。 大部分同步格调的API咱们都通过Hook的办法来接管了,libco会在失当的机会调度协程复原执行。 千万级协程反对 libco默认是每一个协程独享一个运行栈,在协程创立的时候,从堆内存调配一个固定大小的内存作为该协程的运行栈。如果咱们用一个协程解决前端的一个接入连贯,那对于一个海量接入服务来说,咱们的服务的并发下限就很容易受限于内存。为此,libco也提供了stackless的协程共享栈模式,能够设置若干个协程共享同一个运行栈。同一个共享栈下的协程间切换的时候,须要把以后的运行栈内容拷贝到协程的公有内存中。为了缩小这种内存拷贝次数,共享栈的内存拷贝只产生在不同协程间的切换。当共享栈的占用者始终没有扭转的时候,则不须要拷贝运行栈。 libco协程的共享协程栈模式使得单机很容易接入千万连贯,只需创立足够多的协程即可。咱们通过libco共享栈模式创立1千万的协程(E5-2670 v3 @ 2.30GHz * 2, 128G内存),每10万个协程共享的应用128k内存,整个稳固echo服务的时候总内存耗费大略为66G。 协程公有变量 多过程程序革新为多线程程序时候,咱们能够用__thread来对全局变量进行疾速批改,而在协程环境下,咱们发明了协程变量ROUTINE_VAR,极大简化了协程的革新工作量。 因为协程本质上是线程内串行执行的,所以当咱们定义了一个线程公有变量的时候,可能会有重入的问题。比方咱们定义了一个__thread的线程公有变量,本来是心愿每一个执行逻辑独享这个变量的。但当咱们的执行环境迁徙到协程了之后,同一个线程公有变量,可能会有多个协程会操作它,这就导致了变量冲入的问题。为此,咱们在做libco异步化革新的时候,把大部分的线程公有变量改成了协程级公有变量。协程公有变量具备这样的个性:当代码运行在多线程非协程环境下时,该变量是线程公有的;当代码运行在协程环境的时候,此变量是协程公有的。底层的协程公有变量会主动实现运行环境的判断并正确返回所需的值。 协程公有变量对于现有环境同步到异步化革新起了无足轻重的作用,同时咱们定义了一个非常简单不便的办法定义协程公有变量,简略到只需一行申明代码即可。 gethostbyname的Hook办法 对于现网服务,有可能须要通过零碎的gethostbyname API接口去查问DNS获取实在地址。咱们在协程化革新的时候,发现咱们hook的socket族函数对gethostbyname不实用,当一个协程调用了gethostbyname时会同步期待后果,这就导致了同线程内的其它协程被延时执行。 咱们对glibc的gethostbyname源码进行了钻研,发现hook不失效次要是因为glibc外部是定义了__poll办法来期待事件,而不是通用的poll办法;同时glibc还定义了一个线程公有变量,不同协程的切换可能会重入导致数据不精确。最终gethostbyname协程异步化是通过Hook __poll办法以及定义协程公有变量解决的。 gethostbyname是glibc提供的同步查问dns接口,业界还有很多优良的gethostbyname的异步化解决方案,然而这些实现都须要引入一个第三方库并且要求底层提供异步回调告诉机制。libco通过hook办法,在不批改glibc源码的前提下实现了的gethostbyname的异步化。 协程信号量 在多线程环境下,咱们会有线程间同步的需要,比方一个线程的执行须要期待另一个线程的信号,对于这种需要,咱们通常是应用pthread_signal 来解决的。在libco中,咱们定义了协程信号量co_signal用于解决协程间的并发需要,一个协程能够通过co_cond_signal与co_cond_broadcast来决定告诉一个期待的协程或者唤醒所有期待协程。 总结 ...

September 3, 2021 · 1 min · jiezi

关于im:以两军问题为背景来演绎Basic-Paxos

背景在计算机通信实践中,有一个驰名的两军问题(two-army problem),讲述通信的单方通过ACK来达成共识,永远会有一个在途的ACK须要进行确认,因而无奈达成共识。 两军问题和Basic Paxos十分类似 1) 通信的各方须要达成共识; 2) 通信的各方仅须要达成一个共识; 3) 假如的前提是信道不稳固,有丢包、提早或者重放,但音讯不会被篡改。 Basic Paxos最早以希腊议会的背景来解说,但普通人不了解希腊议会的运作模式,因而看Basic Paxos的论文会比拟难了解。两军问题的背景大家更相熟,因而尝试用这个背景来演绎一下Basic Paxos。 为了配合Basic Paxos的多数派概念,把两军改为3军;同时假如了将军和顾问的角色。 假如的3军问题1) 1支红军在山谷里扎营,在四周的山坡上驻扎着3支蓝军; 2) 红军比任意1支蓝军都要弱小;如果1支蓝军独自作战,红军胜;如果2支或以上蓝军同时防御,蓝军胜; 3) 三支蓝军须要同步他们的防御工夫;但他们惟一的通信媒介是派通信兵步行进入山谷,在那里他们可能被俘虏,从而将信息失落;或者为了防止被俘虏,可能在山谷停留很长时间; 4) 每支军队有1个顾问负责提议防御工夫;每支军队也有1个将军批准顾问提出的防御工夫;很显著,1个顾问提出的防御工夫须要取得至多2个将军的批准才有意义; 5) 问题:是否存在一个协定,可能使得蓝军同步他们的防御工夫? 接下来以两个假如的场景来演绎BasicPaxos;顾问和将军须要遵循一些根本的规定 1) 顾问以两阶段提交(prepare/commit)的形式来发动提议,在prepare阶段须要给出一个编号; 2) 在prepare阶段产生抵触,将军以编号大小来裁决,编号大的顾问胜出; 3) 顾问在prepare阶段如果收到了将军返回的已承受防御工夫,在commit阶段必须应用这个返回的防御工夫; 两个顾问先后提议的场景 1) 顾问1发动提议,派通信兵带信给3个将军,内容为(编号1); 2) 3个将军收到顾问1的提议,因为之前还没有保留任何编号,因而把(编号1)保留下来,防止忘记;同时让通信兵带信回去,内容为(ok); 3) 顾问1收到至多2个将军的回复,再次派通信兵带信给3个将军,内容为(编号1,防御工夫1); 4) 3个将军收到顾问1的工夫,把(编号1,防御工夫1)保留下来,防止忘记;同时让通信兵带信回去,内容为(Accepted); 5) 顾问1收到至多2个将军的(Accepted)内容,确认防御工夫曾经被大家接管; 6) 顾问2发动提议,派通信兵带信给3个将军,内容为(编号2); 7) 3个将军收到顾问2的提议,因为(编号2)比(编号1)大,因而把(编号2)保留下来,防止忘记;又因为之前曾经承受顾问1的提议,因而让通信兵带信回去,内容为(编号1,防御工夫1); 8) 顾问2收到至多2个将军的回复,因为回复中带来了已承受的顾问1的提议内容,顾问2因而不再提出新的防御工夫,承受顾问1提出的工夫; 两个顾问穿插提议的场景 1) 顾问1发动提议,派通信兵带信给3个将军,内容为(编号1); 2) 3个将军的状况如下 a) 将军1和将军2收到顾问1的提议,将军1和将军2把(编号1)记录下来,如果有其余顾问提出更小的编号,将被回绝;同时让通信兵带信回去,内容为(ok); b) 负责告诉将军3的通信兵被抓,因而将军3没收到顾问1的提议; 3) 顾问2在同一时间也发动了提议,派通信兵带信给3个将军,内容为(编号2); 4) 3个将军的状况如下 a) 将军2和将军3收到顾问2的提议,将军2和将军3把(编号2)记录下来,如果有其余顾问提出更小的编号,将被回绝;同时让通信兵带信回去,内容为(ok); b) 负责告诉将军1的通信兵被抓,因而将军1没收到顾问2的提议; 5) 顾问1收到至多2个将军的回复,再次派通信兵带信给有回答的2个将军,内容为(编号1,防御工夫1); ...

September 3, 2021 · 1 min · jiezi

关于im:以两军问题为背景来演绎BasicPaxos

背景在计算机通信实践中,有一个驰名的两军问题,讲述通信的单方通过ACK来达成共识,永远会有一个在途的ACK须要进行确认,因而无奈达成共识。 两军问题和BasicPaxos十分类似 1) 通信的各方须要达成共识; 2) 通信的各方仅须要达成一个共识; 3) 假如信道不稳固,有丢包、提早或者重放,但音讯不会被篡改。 BasicPaxos最早以希腊议会的背景来解说,但普通人不了解希腊议会的运作模式,因而看BasicPaxos的论文会比拟难了解。两军问题的背景大家更相熟,因而尝试用这个背景来演绎一下BasicPaxos。 为了配合BasicPaxos的多数派概念,把两军改为3军;同时假如了将军、顾问和通信兵的角色。 假如的3军问题 1) 1支红军在山谷里扎营,在四周的山坡上驻扎着3支蓝军; 2) 红军比任意1支蓝军都要弱小;如果1支蓝军独自作战,红军胜;如果2支或以上蓝军同时防御,蓝军胜; 3) 三支蓝军须要同步他们的防御工夫;但他们惟一的通信媒介是派通信兵步行进入山谷,在那里他们可能被俘虏,从而将信息失落;或者为了防止被俘虏,可能在山谷停留很长时间; 4) 每支军队有1个顾问负责提议防御工夫;每支军队也有1个将军批准顾问提出的防御工夫;很显著,1个顾问提出的防御工夫须要取得至多2个将军的批准才有意义; 5) 问题:是否存在一个协定,可能使得蓝军同步他们的防御工夫? 接下来以两个假如的场景来演绎BasicPaxos;顾问和将军须要遵循一些根本的规定 1) 顾问以两阶段提交(prepare/commit)的形式来发动提议,在prepare阶段须要给出一个编号; 2) 在prepare阶段产生抵触,将军以编号大小来裁决,编号大的顾问胜出; 3) 顾问在prepare阶段如果收到了将军返回的已承受防御工夫,在commit阶段必须应用这个返回的防御工夫; 两个顾问先后提议的场景 1) 顾问1发动提议,派通信兵带信给3个将军,内容为(编号1); 2) 3个将军收到顾问1的提议,因为之前还没有保留任何编号,因而把(编号1)保留下来,防止忘记;同时让通信兵带信回去,内容为(ok); 3) 顾问1收到至多2个将军的回复,再次派通信兵带信给3个将军,内容为(编号1,防御工夫1); 4) 3个将军收到顾问1的工夫,把(编号1,防御工夫1)保留下来,防止忘记;同时让通信兵带信回去,内容为(Accepted); 5) 顾问1收到至多2个将军的(Accepted)内容,确认防御工夫曾经被大家接管; 6) 顾问2发动提议,派通信兵带信给3个将军,内容为(编号2); 7) 3个将军收到顾问2的提议,因为(编号2)比(编号1)大,因而把(编号2)保留下来,防止忘记;又因为之前曾经承受顾问1的提议,因而让通信兵带信回去,内容为(编号1,防御工夫1); 8) 顾问2收到将军的回复,因为回复中带来了已承受的顾问1的提议内容,顾问2因而不再提出新的防御工夫,承受顾问1提出的工夫;顾问2再次派通信兵带信给3个将军,内容为(编号2,防御工夫1); 9) 3个将军收到顾问2的工夫,把(编号2,防御工夫1)保留下来,防止忘记;同时让通信兵带信回去,内容为(Accepted); 10) 顾问2收到至多2个将军的(Accepted)内容,确认防御工夫曾经被大家接管; 两个顾问穿插提议的场景 1) 顾问1发动提议,派通信兵带信给3个将军,内容为(编号1); 2) 3个将军的状况如下 将军1和将军2收到顾问1的提议,因为还没有其余顾问提议,因而将军1和将军2把(编号1)记录下来;同时让通信兵带信回去,内容为(ok);负责告诉将军3的通信兵被抓,因而将军3没收到顾问1的提议;3) 顾问2在同一时间也发动了提议,派通信兵带信给3个将军,内容为(编号2); 4) 3个将军的状况如下 将军2和将军3收到顾问2的提议,将军2和将军3把(编号2)记录下来;将军2记录编号2,是因为编号2比之前记录的编号1大;将军3记录编号2,是因为之前没有顾问向他提议;这两个将军同时让通信兵带信回去,内容为(ok);负责告诉将军1的通信兵被抓,因而将军1没有收到顾问2的提议;5) 顾问1收到至多2个将军的回复,再次派通信兵带信给有回答的2个将军,内容为(编号1,防御工夫1); 6) 2个将军的状况如下 将军1收到了(编号1,防御工夫1),和本人保留的编号雷同,因而把(编号1,防御工夫1)保留下来;同时让通信兵带信回去,内容为(Accepted);将军2收到了(编号1,防御工夫1),因为(编号1)小于曾经保留的(编号2),因而让通信兵带信回去,内容为(Rejected,编号2);7) 顾问2收到至多2个将军的回复,再次派通信兵带信给有回答的2个将军,内容为(编号2,防御工夫2); 8) 将军2和将军3收到了(编号2,防御工夫2),和本人保留的编号雷同,因而把(编号2,防御工夫2)保留下来,同时让通信兵带信回去,内容为(Accepted); ...

September 2, 2021 · 1 min · jiezi

关于im:Paxos理论介绍4-动态成员变更

多数派的实质在解说成员变更之前,咱们先回顾一下前文介绍的Paxos实践第一篇文章 Paxos实践介绍(1): 奢侈Paxos算法实践推导与证实, (认真回顾数学定义和投票束缚章节)文中提到Bqrm为一轮胜利投票所须要的投票者汇合,而Paxos算法实践第二条束缚要求任意两个Bqrm的交加不为空,于是乎咱们能够了解为Bqrm就是一个多数派的意思,因为在一个固定的投票者汇合外面,取多数派作为Bqrm,必定是满足条件的。 而所有的实践介绍,都是基于投票者汇合是固定的。一旦投票者汇合呈现变动,Bqrm的定义将不再是多数派,Bqrm的取值将变得异样艰难,而无奈定义Bqrm,Paxos算法的束缚就无奈达成一致性。也就是说,固定的成员是Paxos算法的根基。 人肉配置进行成员变更?咱们再进行第二篇文章 Paxos实践介绍(2): Multi-Paxos与Leader 的回顾,通过文章咱们晓得Paxos是以独立的实例的形式推动,从而产生一个统一的有序的系列,而每个实例都是独自运作的Paxos算法。再依据上文,咱们得出一个要求,在雷同的实例上,咱们要求各个成员所认为的成员汇合必须是统一的,也就是在一次残缺的Paxos算法外面,成员其实还是固定的。 每个成员如何得悉这个成员汇合是什么?通常咱们是通过配置文件。在通过配置的变更是否满足以上的要求呢?咱们晓得Multi-Paxos在推动的过程中是容许少数派落后的,而在同一个实例外面,获知Value被chosen也是有先后的,那么配置的变更可能呈现在以上任何的先后夹缝内,下图演示一个更换节点C为D的样例。 注:绿色代表曾经获知chosen value的实例能够察看到4这个实例,曾经呈现了成员凌乱,(A,C),(B,D)都能够被认为是Bqrm,但显著这两个Bqrm没有交加,曾经违反Paxos协定。 事实上咱们谋求的是找到一个切入机会,使得Paxos的运作程序都在这雷同的时刻实现配置的原子切换,但显著在分布式环境外面能做原子切换的只有一致性算法,所以配置更新不靠谱。 题外话,如果真的要应用人肉配置更新,在工程上是有一些方法,通过一些工具加人肉的轻微察看来有限迫近这个正确性,但究竟只能迫近。在实践层面咱们会放大任何事实中可能不会呈现的轻微谬误,比方工夫的不同步,网络包在交换机有限停留,操作系统调度导致的代码段卡壳等等,这些都会导致这些人肉办法不能回升到实践层面。况且,咱们接下来要介绍的动静成员变更算法也是十分的简略。所以这些粗疏的问题就不开展来聊了。Paxos动静成员变更算法这个算法在 Paxos Made Simple 的最初一段被一句话带过,可能作者认为这个是瓜熟蒂落的事件,基本不值一提。 Multi-Paxos决定出的有序系列,个别被用来作为状态机的状态转移输出,统一的状态转移得出统一的状态,这是Paxos的根本利用。那么十分瓜熟蒂落的事件就是,成员(投票者汇合)自身也是一个状态,咱们通过Paxos来决定出成员变更的操作系列,那么各台机器就能取得统一的成员状态。如下图。 在4这个实例,咱们通过Paxos算法来决定一个成员变更操作,所有的节点在实例4之后都能获取到成员从A,B,C变成了A,B,D,在实践上达到了原子变更的要求。 延缓变更失效 通常Paxos的工程化为了性能和停顿性都会由一个Leader节点进行数据写入,而成员变更往往可能会导致Leader节点发生变化。那么变动的霎时可能会呈现大量以后Leader节点沉积申请的失败。 另外如果采纳多个实例基于窗口滑动并行提交(这里临时不开展讲,而且我感觉这个在理论工程实现中必要性也不是很大)的话,在成员变更操作被chosen后,之后的实例可能还在Paxos算法运行当中,那么这些实例的Bqrm可能曾经被确定下来,所以咱们不能再去改变这些实例的Bqrm。如上图例子,4的时候进行了成员变更,然而因为并行提交的关系,5和6可能都曾经在提交当中了,那么他的Bqrm还是被确定下来为A,B,C,这时候咱们不能去改这些实例的Bqrm为A,B,D。 为了解决这个问题,咱们能够将成员失效时间延缓一下,在这个期间将申请疏导到新的写入节点。 咱们能够定义一个延缓窗口为a,成员变更点为I,则失效点为I + a。这个a依据理论状况进行调节。如上图,成员变更点在实例4,然而失效点能够在实例6之后。咱们规定旧的Leader在I + a之前依然能失常写入数据,而新的写入节点必须从I + a开始写入数据,这样能够实现一个平滑过渡。 这里有个异常情况,如果成员变更后,旧的Leader不写入数据了,实例停留在(I, I + a), 而新的写入节点因为要在I + a后能力写入数据,真个算法就卡住无奈进行申请写入了。这种状况须要在工程上进行察看,如果呈现则由新的写入节点对(I, I + a)进行nullvalue的写入,从而填补空洞。 说的再多不如浏览源码,猛击进入咱们的开源Paxos类库实现:https://github.com/tencent-wechat/phxpaxos, 咱们残缺的实现成员变更算法。OpenIMgithub开源地址: https://github.com/OpenIMSDK/... OpenIM官网 : https://www.rentsoft.cn OpenIM官方论坛: https://forum.rentsoft.cn/ 更多技术文章: 开源OpenIM:高性能、可伸缩、易扩大的即时通讯架构https://forum.rentsoft.cn/thr... 【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理https://forum.rentsoft.cn/thr...

September 2, 2021 · 1 min · jiezi

关于im:微信PaxosStore内存云揭秘十亿Paxos分钟的挑战

PaxosStore是微信设计的一套分布式存储系统,并已对外围业务存储做了架构革新。内存云是微信PaxosStore存储体系的组成部分,本文将分享内存云的Paxos革新过程。 作者简介 魏澄,微信高级工程师,目前负责微信根底存储服务,致力于强统一、高可用的大规模分布式存储架构的设计与研发。 微信存储QuorumKV是一个分布式的存储系统,笼罩但不限于微信后盾外围业务:账号/用户信息/关系链/朋友圈,等等。 过来的一年,咱们受Google MegaStore启发,从新设计了一套全新的分布式存储系统,即PaxosStore分布式存储,并于最近半年对外围业务存储做了架构革新,目前已胜利上线并实现了数千台机器的平滑切换,零碎首次拜访成功率晋升一个量级,并取得更好的容灾能力,可用性显著加强。 内存云作为微信PaxosStore存储体系的组成部分,目前存储着微信根底账号、音讯计数等外围用户数据,每天峰值申请高达数十亿/分钟,本文将向大家分享内存云的Paxos革新过程。 背景 微信内存云,目前有2千多台机器:单机内存64GB,存储盘为机械盘。作为外围存储之一,内存云承载了根底账号、音讯计数等外围数据的存储,保障微信登录、音讯收发等微信根底性能。内存云每天服务峰值申请十多亿/分钟,读写比约为3.3:1。基于QuourmKV的内存云具体架构如图1所示: 图1 QuorumKV架构 微信QuourmKV陪伴内存云走过了数次扩容,经验除夕、春晚等例行节日申请暴发增长的洗礼,也积淀着不少故障解决教训(不限内存云)。本文次要形容新架构如何根本性地改善QuorumKV的容灾能力(即CAP中,保障C的前提下加强A),在不就义性能的前提下,毁灭局部故障场景下的最终失败和人为染指。 QuorumKV实质上是一个NWR协定(N为3,W/R为2)的分布式存储,和其余NWR协定不同的中央在于:QuorumKV将NWR利用在版本上,当且仅当版本达成统一的状况下读写单机数据,从而保障强一致性。然而这里引入了2个问题: 数据写一份,依附异步同步至对机;当WR无奈造成少数时,单Key不可用,需进行修复。不要小看了这2个问题,这是目前QuorumKV的绝大部分日常故障导致失败的本源,特地是对写量大的模块而言: 数据机故障离线,局部Key最新数据在故障机上,不可用;版本机故障离线,局部Key(版本不平)仲裁失败,不可用。 表2 分布式协定比照 明确问题的本源是QuorumKV采纳的NWR分布式协定,那么在保障强一致性的前提下可行的解决方案为Paxos/Raft分布式协定。表2列出了咱们在协定抉择上的一些考量:采纳无租约的形式使得零碎在保障强一致性的前提下达到最大的可用性;相对而言,租约的形式必然引入主备切换导致的不可用。 在比照调研过一些业界计划(etcd/megastore等)后,咱们最终确定新架构协定计划是:无租约版Paxos分布式协定(如图3所示)。 图3 新架构(无租约版Paxos分布式协定) 面向挑战 接下来须要做的事件是,基于Paxos分布式协定在机械盘上搭建一套稳固高性能的分布式存储。 挑战1:Paxos分布式协定 咱们在谈及Paxos算法时,通常会提及Leslie Lamport大神的Paxos Made Simple;但基于Paxos算法的分布式协定不止与此,图4列出一个残缺协定波及的3个档次。 图4 Paxos分布式协定 Paxos算法 PaxosStore孕育了2套Paxos算法组件:Paxos Certain组件和Paxos KV组件,内存云应用的正是其中的PaxosKV算法组件。Paxos KV组件外围代码1912行,通过严格测试,目前用于线上多个Key-Value存储模块,包含但不限于:用户账号信息存储、朋友圈存储等。 PaxosLog 在构建PaxosLog(简称为PLog)时,咱们针对Key-Value存储做了2项优化。 第一,PLog as DB 一般青年的通常做法是PLog和DB拆散:增量更新记录在PLog中,并在Chosen之后程序利用到DB中。这里的问题在于: 至多2次写操作:1次PLog写,1次DB写。Key和PLog的对应关系:N : 1 读写性能受限与单个PLog;1 : 1 雷同的数据反复写2次。 图5 精简1:plog as db 提高青年思考了下得出PLog as DB计划:咱们心愿Key和PLog放弃1:1的对应关系,从而达到最大的并发性能,同时又不引入反复写。 第二, 精简的PLog: 只保留最新的LogEntry ...

September 2, 2021 · 2 min · jiezi

关于im:Paxos理论介绍3-Master选举

前文:Paxos实践介绍(2): Multi-Paxos与Leader 倡议没有浏览后面文章的读者能够先花少许工夫浏览一下。 Master单刀直入,咱们先明确一下Master的定义。Master是一个角色,这个角色的特点是,在咱们选定的一些节点汇合内,任一时刻,仅有一个节点成为Master或者没有任何节点成为Master。这是一个十分严格的单点定义。 Master的利用十分宽泛。比方在分布式存储外面,咱们心愿读取一个最新的值,那么常见的做法是咱们先选举出一个Master,读写都经由Master来实现,那么在Master上读取到的就必定是最新的。另外还比方一些仲裁模块,往往也心愿有Master来帮助。 Master选举与Paxos的关系如何选举Master?因为Master具备严格的单点定义,那么必须有一个强一致性的算法能力实现选举,当然咱们这里采纳了Paxos。但Master选举算法本身也是一个通用性的算法,它能够与任何强一致性算法搭配来实现,而无需要求肯定是Paxos。所以这里咱们心愿设计一个与Paxos齐全解耦的工程实现,也就是Master选举只用到Paxos工程实现的API,而无需侵入Paxos算法外部。 Paxos的工程利用这个波及到Paxos工程上API设计以及状态机,这里先不开展讲,来看一张图置信大家就懂了,图片来自论文"Paxos Made Live"。 Paxos的利用扼要来讲就是由算法确定一个操作系列,通过编写这些操作系列的callback(也就是状态机的状态转移函数),使得节点进行雷同程序的callback,从而保障各个节点的状态统一。 Master选举租约算法 BeMaster是一个操作,这个操作很简略,就是提议本人成为Master,图片外面A节点心愿本人成为Master。任何节点都能够发动这个操作尝试将本人晋升为Master,除了曾经得悉他人已被选为Master。当得悉他人被选为Master后,必须期待timeout长度工夫,能力发动BeMaster操作。而如果是获知本人成为Master,那么从BeMaster开始的timeout工夫内可认为本人是Master,如图示,T2-T3的工夫窗内,视作Master的任期。 如何将下面所述的租约算法与Paxos联合起来? BeMaster能够认为是一个Submit操作,其Value携带的就是本人的节点信息。callback做两件事件,第一:发现Value的节点非本人,则期待timeout工夫再发动BeMaster。第二:发现Value的节点是本人,那么将本人晋升为Master,并在T(BeMaster) + timeout后过期。算法正确性如何保障? 一致性由Paxos保障,也就是只有Value被Paxos选出来,那么其蕴含的必定是同一个节点信息,不会呈现选举抵触。Master的单点性通过租约算法保障。因为恒定T(BeMaster) < T(Know other as master),那么Master的过期工夫必定要比非Master节点认为Master过期的工夫早,从而保障Master任期内,必定不会呈现其余节点尝试来抢占Master。这里给大家提一个问题,图示外面,为何Master任期的起始工夫是从BeMaster算起,而不能是从BeMaster success算起?置信如果了解了Paxos算法的读者,应该能够很轻松答复这个问题。Master续任 只须要在Master任期内胜利胜利实现一次BeMaster操作,即可缩短Master任期,在失常状况下这样一直迭代上来,个别会使得Master十分的稳固。 上图能够看到在屡次的BeMaster选举外面,咱们须要给每一个任期赋予一个version,这是为什么?上面通过一个例子来解释这个问题。 这个图示状况是NodeA一直的在续任,但NodeC可能与NodeA无奈通信或者其余起因,在获知NodeA第二次续任胜利后就再也收不到任何音讯了,于是当NodeC认为A的Master任期过期后,即可尝试发动BeMaster操作。这就违反了算法的保障了,呈现了NodeA在任期内,但NodeC发动BeMaster操作的状况。 这里问题的实质是,NodeC还未取得最新的Master状况,所以发动了一次谬误的BeMaster。version的退出是参考了乐观锁来解决这个问题。发动BeMaster的时候携带上一次的version,如果这个version曾经不是最新,那么这一次BeMaster天然会生效,从而解决问题。了解乐观锁的读者应该能够很快脑补出version的作用,这里就不具体开展了。 小贴纸说的再多不如浏览源码,猛击进入咱们的开源Paxos类库实现:https://github.com/tencent-wechat/phxpaxos 在src/master目录有残缺的Master租约算法实现代码。OpenIMgithub开源地址: https://github.com/OpenIMSDK/... OpenIM官网 :https://www.rentsoft.cn OpenIM官方论坛:https://forum.rentsoft.cn/ 更多技术文章: 开源OpenIM:高性能、可伸缩、易扩大的即时通讯架构https://forum.rentsoft.cn/thr... 【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理https://forum.rentsoft.cn/thr...

September 1, 2021 · 1 min · jiezi

关于im:Paxos理论介绍2-MultiPaxos与Leader

前文:Paxos实践介绍(1): 奢侈Paxos算法实践推导与证实 了解奢侈Paxos是浏览本文的前提。 Multi-Paxos奢侈Paxos算法通过多轮的Prepare/Accept过程来确定一个值,咱们称这整个过程为一个Instance。Multi-Paxos是通过Paxos算法来确定很多个值,而且这些值的程序在各个节点完全一致。概括来讲就是确定一个全局程序。 多个Instance怎么运作?首先咱们先构建最繁难的模式,各个Instance独立运作。 每个Instance独立运作一个奢侈Paxos算法,咱们保障仅当Instance i的值被确定后,方可进行i+1的Paxos算法,这样咱们就保障了Instance的有序性。但这样效率是比拟差的,家喻户晓奢侈Paxos算法的Latency很高,Multi-Paxos算法心愿找到多个Instance的Paxos算法之间的分割,从而尝试在某些状况去掉Prepare步骤。 上面我尝试形容一个Sample的演进状况来论述这个算法,因为这个算法的要点其实非常简单,而且无需更多证实。 首先咱们定义Multi-Paxos的参加因素: 3个参加节点 A/B/C.Prepare(b) NodeA节点发动Prepare携带的编号。Promise(b) NodeA节点承诺的编号。Accept(b) NodeA节点发动Accept携带的编号。1(A)的意思是A节点产生的编号1,2(B)代表编号2由B节点产生。绿色示意Accept通过,红色示意回绝。下图形容了A/B/C三个节点并行提交的演进过程: 这种状况下NodeA节点简直每个Instance都收到其余节点发来的Prepare,导致Promise编号过大,迫使本人一直晋升编号来Prepare。这种状况并未能找到任何的优化突破口。 下图形容了只有A节点提交的演进过程: 这种状况咱们会立即发现,在没有其余节点提交的烦扰下,每次Prepare的编号都是一样的。于是乎咱们想,为何不把Promised(b)变成全局的?来看下图: 假如咱们在Instance i进行Prepare(b),咱们要求对这个b进行Promise的失效范畴是Instance[i, ∞),那么在i之后咱们就无需在做任何Prepare了。可想而知,假如上图Instance 1之后都没有任何除NodeA之外其余节点的提交,咱们就能够预期接下来Node A的Accept都是能够通过的。那么这个去Prepare状态什么时候突破?咱们来看有其余节点进行提交的状况: Instance 4呈现了B的提交,使得Promised(b)变成了2(B), 从而导致Node A的Accept被回绝。而NodeA如何持续提交?必须得进步本人的Prepare编号从而抢占Promised(b)。这里呈现了很显著的去Prepare的窗口期Instance[1,3],而这种期间很显著的标记就是只有一个节点在提交。 重点:不Prepare间接Accept为啥是平安的?因为Accept的b曾经被Promise过。 总结 Multi-Paxos通过扭转Promised(b)的失效范畴至全局的Instance,从而使得一些惟一节点的间断提交取得去Prepare的成果。 题外话:这里提一下我所察看到的Multi-Paxos的一个误区,很多人认为Multi-Paxos是由leader驱动去掉Prepare的,更有说在有Leader的状况下能力实现Multi-Paxos算法,这都是了解有误。大家看到这里也应该明确这里的因果关系,Multi-Paxos是适应某种申请特色状况下的优化,而不是要求申请满足这种特色。所以Multi-Paxos承受并行提交。Leader为何还要说Leader,尽管Multi-Paxos容许并行提交,但这种状况下效率是要进化到奢侈Paxos的,所以咱们并不心愿长时间处于这种状况,Leader的作用是心愿大部分工夫都只有一个节点在提交,这样能力最大施展Mulit-Paxos的优化成果。 怎么失去一个Leader,真的十分之简略,Lamport的论文甚至的不屑一提。咱们察看Multi-Paxos算法,首先能做Accept(b)必然是b曾经被Promised了,而间断的Accept(b)被打断,必然是因为Promised(b)被晋升了,也就是呈现了其余节点的提交(提交会先Prepare从而晋升b)。那么重点来了,如何防止其余节点进行提交,咱们只须要做一件事即可实现。 收到来自其余节点的Accept,则进行一段时间的回绝提交申请。 这个解读起来就是各个节点都想着不要去突破这种间断的Accept状态,而当有一个节点在间断的Accept,那么其余节点必然继续一直的拒绝请求。这个Leader就这样有形的被产生进去了,咱们压根没有刻意去“选举”,它就是来自于Multi-Paxos算法。 题外话:为何网上呈现很多非常复杂的选举Leader算法,有的甚至利用Paxos算法去选举Leader,我觉的他们很有可能是没有齐全了解Multi-Paxos,走入了必须有Leader这个误区。用Paxos算法来进行选举是有意义的,但不应该用在Leader下面。Paxos的利用除了写之外,还有很重要的一环就是读,很多时候咱们心愿要读到Latest,通常的做法就是选举出一个Master。Master含意是在任一时刻只能有一个节点认为本人是Master,在这种束缚下,读写我都在Master上进行,就能够取得Latest的成果。Master与Leader有实质上的区别,要达到Master这种强统一的唯一性,必须得通过强一致性算法能力选举进去。而当咱们实现了Paxos算法后,选举Master也就变得非常简单了,会波及到一些租约的货色,前面再分享。 说的再多不如浏览源码,猛击进入咱们的开源Paxos类库实现:https://github.com/tencent-wechat/phxpaxosOpenIMgithub开源地址: https://github.com/OpenIMSDK/... OpenIM官网 :https://www.rentsoft.cn OpenIM官方论坛:https://forum.rentsoft.cn/ 更多技术文章: 开源OpenIM:高性能、可伸缩、易扩大的即时通讯架构https://forum.rentsoft.cn/thr... 【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理https://forum.rentsoft.cn/thr...

September 1, 2021 · 1 min · jiezi

关于im:谈谈PhxSQL的设计和实现哲学上

开源地址 GitHub - tencent-wechat/phxsql: A high availability MySQL cluster that guarantees data consistency between a master and slaves. 摘要微信PhxSQL是一个提供Zookeeper级别强统一和高可用的MySQL集群。PhxSQL齐全兼容MySQL,建设在简略可逻辑证实的一致性模型之上,架构、部署、运维简略。文章还探讨了PhxSQL与相干技术计划的区别,并比拟了各自的优缺点。 文章比拟长,注释分成高低两章。上章次要探讨why,即咱们为什么要做PhxSQL以及为什么这样做。下章着重探讨why not,即咱们为什么不反对若干个性,例如多主多写和分库分表,及与Galera和MySQL Group Replication的比拟等。 注释PhxSQL[22]公布以来,受到很多关注。作为酷爱技术的码农,咱们感激大家的关怀和反对,欢送所有基于技术出发点的探讨。“Show you the code”之后,咱们在这里谈谈PhxSQL的设计和实现哲学,也同时答复大家提出的一些疑难。 1. PhxSQL是什么? PhxSQL是一个通过Paxos保障强统一和高可用的的MySQL集群。PhxSQL建设在Paxos的一致性和MySQL的binlog流水根底上。次要原理简略来说: i) Paxos选出主机 ii) 主机把本机MySQL设置成可写的MySQL主机,在MySQL写binlog流程中拦挡binlog流水、发送到Paxos,造成全局的binlog流水 iii) 备机把本机的MySQL设置成只读的MySQL备机,MySQL备机从全局binlog中拉取流水,重放和执行,从而主备MySQL统一 iv) 针对常见的业务场景,PhxSQL提供两个服务端口:强统一读写端口(ReadWritePort)和只读端口(ReadonlyPort);对数据要求强统一的业务,通过ReadWritePort来读写;只要求能读取但不要求最新数据的读申请(比方一些定时对账业务),能够通过ReadonlyPort来读取 只有有多于一半机器工作和互联,PhxSQL就能够失常工作。 图 1:PhxSQL架构 2. PhxSQL的”强统一“和”高可用“是什么级别? 很多MySQL集群计划都声称强统一和高可用。PhxSQL这方面有什么不同? 大家熟知的Zookeeper提供强统一和高可用。一致性有很多级别,从强到弱别离是:Strict(严格一致性),Linearizable(线性一致性)[1],Sequential(序列一致性)[2],Causal(因果一致性),Eventual等。具体定义请参见参考文献。严格一致性只是一个实践模型。依据相对论,因为信息流传的速度不可能高于光速,严格一致性在理论中简直无奈实现。线性一致性的实践定义很简单,不太谨严直观地讲,就是任何一个客户端都能够读到别的客户端写入的最新内容。这也是大家通常了解的强统一。 Zookeeper的强统一指“线性一致性”[3]。高可用是说只有多于一半机器工作和互联即可在保障线性一致性的品质下失常工作。PhxSQL的强统一是指“线性一致性”,高可用是指只有多于一半机器工作和互联即可在保障线性一致性品质下工作。即, PhxSQL提供和Zookeeper雷同的强一致性和高可用性! PhxSQL提供和Zookeeper雷同的强一致性和高可用性! PhxSQL提供和Zookeeper雷同的强一致性和高可用性! 重要事件说三遍:)。大家能够把PhxSQL当Zookeeper应用,例如用来选主! 在数据库事务隔离方面,PhxSQL反对最高级别的serializable。在性能方面,PhxSQL提供显著优于MySQL半同步的写性能(在基准测试中晋升16%到25%)和简直雷同的读性能[22]。 仔细的读者可能留神到,和通常的“高可用、强统一”说法程序相同,这个大节的题目中,“强统一”无意放在了“高可用”的后面。在这里须要廓清一个误区。当谈到高可用时,有时会有意无意疏忽或者升高一致性。严格意义上来讲,可用性和一致性必须一块探讨,满足一致性要求前提下的可用性才有意义。打个不谨严的比如,一致性就像汽车的“安全性”,可用性就是汽车的“可用性”。如果一辆车号称“可用性”很好,能够间断工作10年,但从来不提“安全性”,那么这辆车的品质是值得狐疑的。 3. 为什么要做PhxSQL? 尽管有很多NoSQL、NewSQL零碎、以及多主多写MySQL集群、反对分库分表的MySQL集群,MySQL传统主备同步计划依然具备很多新零碎难以企及的长处。MySQL主备在主机上反对残缺SQL、全局事务、以repeatable read和serializable级别的事务隔离,在金融、帐号等要害业务中有微小的价值。同时,现有简单MySQL利用迁徙到新的非兼容零碎老本也很高。 然而MySQL传统主备计划也有其毛病。最显著的就是主机故障后的主动换主和新旧主数据一致性(以及衍生的换主后主备一致性、各个备机之间一致性,这里就不详加探讨了),即所谓的一致性和可用性。 为了解决这个问题,有传统流派:用Zookeeper、etcd、或者其它第三方来检测心跳、选主、和切换。革新MySQL client让其能感知新的主机。或者为了能让传统MySQL client不加批改就能感知新的主机,部署MySQL代理服务器,让其将连到本身的MySQL client申请通明转发给新的主机。为了缩小主备间数据的落后,从而升高旧主机故障、某台备机被晋升成新主机时,新旧主机之间、新主机和其它备机之间的差别,很多计划在主备同步机制上做了很多无益的工作。例如semi-sync期待多数派备机应答,通过优化线程和网络、主备多通道、备机并行执行binlog流水等尽量减少主备之间差别。如果主备间任何时刻都完全一致,那么任何时刻换主都是强统一的。这句话的另外一个意思是,如果无奈保障主备间任何时刻完全一致,那么当有继续一直的更新时,任何时刻的换主都是无奈保障强统一的。 传统流派另外一个分支就是将MySQL本地磁盘换成更高可靠性的SAN,当MySQL主机故障时,将SAN挂接到备机上提供服务。而当SAN故障时怎么办?当须要跨机房部署时怎么办? 意识到传统流派的局限性,新出了Galera和MySQL Group Replication等。除了声称提供强一致性和高可用性外,还反对master-master多点写入等迷人新个性。 世界上目前已知的通过实践证实和理论测验的一致性算法比比皆是:两阶段提交two-phase commit (2PC)、Paxos[4]、Raft[5]、Zookeeper Atomic Broadcast (ZAB)[3]、Viewstamped Replication[5]等。2PC尽管能够保障一致性,但在主机故障时无奈工作,存在可用性问题。目前被工业界宽泛认可和利用的是Paxos和Raft,2PC个别在前两者帮忙选主下应用。这里的一个小倡议就是:如果一个分布式系统声称反对线性一致性级别的强统一和高可用,请先查看它应用的一致性算法。如果是新算法,请查看它的形式化证实或者逻辑证实。 ...

September 1, 2021 · 2 min · jiezi

关于im:谈谈PhxSQL的设计和实现哲学下

摘要 上一章探讨了咱们为什么要做PhxSQL和为什么这样做PhxSQL。这里咱们次要谈谈为什么不做某些个性。舍得舍得,有舍才有得。CAP通知咱们只能三选二,俗话通知咱们天下没有收费的午餐。每个个性除了本身提供的性能,也有其代价。为了保障强统一的线性一致性、高可用、serializable级别事务隔离、齐全兼容MySQL、和最小侵入MySQL,PhxSQL放弃了一些个性。 注释7. Why Not? 7.1. 为什么不反对多写? 多写想想就很迷人。多写能够充分利用每台机器写时须要的资源。例如某些写操作可能十分消耗CPU,多写能够把写操作扩散在各台机器上,充分利用各个机器的CPU资源,极大进步写入的性能。多写使得换主没有存在的必要,也就没有换主时可能存在的不可写工夫窗问题。多写还使得客户端能够就近写入,缩小跨数据中心写入带来的网络提早。 多写有两种:大家熟知的分shard或者组,各shard或者组间并行写入,以Google Spanner[8]为典型代表;在shard或者组内并行,以Galera和MySQL Group Replication为代表。 7.1.1. 组间多写 组间多写是把数据分成多个不相交的shard,每个组的机器负责一个shard 。当一个事务波及的数据(读汇合和或写汇合)都在某个组时,这种事务称为本地事务。当一个事务波及的数据分布在超过一个组时,这种事务称为分布式事务。 本地事务能够在本组独立执行,组之间不须要任何通信。为了缩小事务抵触带来的性能升高,个别都是由组内leader执行本地事务,通过Paxos等一致性协定保障组内机器的数据统一[8]。各个组间并行执行本地事务,能够极大进步本地型事务的写性能。 组间多写最大的妨碍是分布式事务,而分布式事务是十分低廉的。在SQL的模型中,为了实现read repeatable级别的事务隔离,事务管理器须要查看两个并发事务的写数据集是否抵触;为了达到serializable级别的事务隔离,事务管理器须要查看两个并发事务的读数据集和写事务集是否抵触[10]。这个别通过严格两阶段锁(strict two-phase locking,严格2PL)和/或者多版本并发管制MVCC实现。当这些数据集跨组时,就波及到跨组的机器通信。 一个组同时遇到本地事务和分布式事务时,在本组须要依据事务的隔离级别,由事务管理器仲裁执行。 以Google Spanner为例,一个波及两个机器组(Spanner中的组是指Paxos组)事务就须要在coordinator leader和non-coordinator-participant leader之间两次通信,前者组内还波及一次Paxos写操作,后者组内再加两次Paxos写操作[8,Sec. 4.2.1 Read-Write Transactions]。当跨机房部署时,机器之间的网络提早使得通信代价更加昂扬。Spanner为了缩小这种低廉的跨组事务,要求所有数据都必须有Primary key,并且其它数据尽量挂接在Primary key上面,使得事务尽量在一个组内、且由组内leader执行。 7.1.2. 组内多主多写 组内多主多写时每个机器都有残缺的数据,但这份数据分成不相交的逻辑汇合,每个机器负责一个汇合的写入。这台机器称为这个汇合的主机,这个汇合称为这个主机负责的数据,其它机器称为这个汇合的备机。客户端将写操作发到所波及数据的主机,由主机通过atomic broadcast原子播送将更新申请发送给组内所有的机器,包含主机自身[9]。Galera和MySQL Group Replication都是采纳这种办法。 图 3:组内多主多写架构[9] 原子播送具备3个个性: i) 如果一台机器执行一条音讯所带的更新命令,那么所有的其它机器都执行这条命令(delivered)。这里“执行”指的是原子播送层将音讯交给下层,实在的执行时刻由下层决定。在数据库中,这个下层个别是并发事务管理器,它决定这些音讯的实在执行程序。 ii) 所有机器以雷同的程序执行命令。 iii) 如果一台机器胜利播送了一条音讯,那么最终所有机器都将执行这条音讯。 应用原子播送后,事务的生命周期从prepare->committed/aborted扭转为prepare->committing->committed/aborted。 图 4:事务生命周期状态转换[9] 当一个事务只波及到一个汇合的数据时,称为本地事务,由这个汇合的主机的本地事务管理器先应用本地严格2PL仲裁,而后将committing状态的事务通过原子播送发给其它备机。 当一个事务波及到多于一个汇合的数据时,称为复合事务(complex transaction)。这个事务所波及的某个数据汇合的主机将committing事务状态,包含读汇合(如果须要serializable级别隔离。这里的一个小优化是采纳dummy row缩小可能极其宏大的读汇合[10])、写汇合、以及committing状态,通过原子播送发给全组进行仲裁。Galera和MySQL Group Replication都只是校验写汇合,因而不反对serializable级别事务隔离[18]。 每台机器都能够通过本地事务状态和原子播送收到的音讯,独立断定committing事务最终是提交还是终止。这种断定由原子播送的个性保障全局统一。 图 5:Deferred Update Replication和Certification-based Replication事务执行时序[11] 强调一下:在机器通过原子播送进行数据同步时,事务的最终后果不能在播送前决定,而是在执行这条音讯依赖的前置音讯及这条音讯后能力决定。这称为Deferred Update Replication9推延的更新复制或者Certification-based Replication[11]。这里有个重要特点须要留神:只有收到一条音讯的所有前置音讯后,这条音讯和所有未执行的前置音讯能力由事务管理器并发执行。因而,这里引入了肯定的串行化。 原子播送的突出长处是在低提早局域网有很高的吞吐率。 ...

September 1, 2021 · 3 min · jiezi

关于im:微信开源CC-RPC框架PhxRPC

微信开源C/C++ RPC框架PhxRPC PhxRPC是微信后盾团队推出的一个十分简洁玲珑的RPC框架,编译生成的库只有450K。 PhxRPC开源地址: https://github.com/tencent-we... 总览应用Protobuf作为IDL用于形容RPC接口以及通信数据结构。基于Protobuf文件主动生成Client以及Server接口,用于Client的构建,以及Server的实现。半同步半异步模式,采纳独立多IO线程,通过Epoll治理申请的接入以及读写,工作线程采纳固定线程池。IO线程与工作线程通过内存队列进行交互。提供欠缺的过载爱护,无需配置阀值,反对动静自适应拒绝请求。提供繁难的Client/Server配置读入形式。基于lambda函数实现并发拜访Server,能够十分不便地实现Google提出的 Backup Requests 模式。局限不反对多过程模式。性能应用Sample目录下的Search RPC C/S进行Echo RPC调用的压测,相当于Worker空转状况。运行环境CPU:24 x Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz内存:32 GB网卡:千兆网卡Client/Server机器之间PING值: 0.05ms申请写入并发:1000个线程业务数据大小:除去HTTP协定局部20bWorker线程数:20性能测试后果(qps)短连贯ucontext类型/IO线程13820system4.1w8.5w9w9.2wboost4.5w9.5w9.5w9.5w长连贯ucontext类型/IO线程13820system5.5w16w36w50wboost6.2w17.5w41w50w如何应用编写proto文件上面是sample目录下的proto文件样例。 生成代码(PhxRPC根目录)/codegen/phxrpc_pb2server -I (PhxRPC根目录) -I (Protobuf include目录) -f (proto文件门路) -d (生成代码搁置门路)#sample../codegen/phxrpc_pb2server -I ../ -I ../third_party/protobuf/include -f search.proto -d .调用完工具后,在生成代码搁置目录下执行make,即可生成全副的RPC相干代码。抉择是否启用boost优化关上生成代码搁置目录下的Makefile文件。 #choose to use boost for network#LDFLAGS := $(PLUGIN_BOOST_LDFLAGS) $(LDFLAGS)能够看到以上两行,勾销正文掉第二行,从新make clean, make即可开启boost对PhxRPC的优化。开启前记得编译好PhxRPC的boost插件。 补充本人的代码Server(xxx_service_impl.cpp) Client (xxx_client.cpp) Client并发调用样例 uthread_begin, uthread_end, uthread_s, uthread_t这几个关键字是PhxRPC自定义的宏,别离示意协程的筹备,完结,协程调度器以及协程的创立。 下面的代码实现了Google提出的 Backup Requests 模式。实现的性能是别离对两个Server同时发动Echo调用,当有一个Server响应的时候,则整个函数完结。在这段代码外面,咱们提供了一种异步IO的同步写法,并给予了一些方便使用的宏定义。首先应用uthread_begin进行筹备,而后应用uthread_t以lambda的模式创立一个协程,而在任意一个协程外面都可应用咱们PhxRPC生成的Client API进行RPC调用,并可应用uthread_s随时完结所有RPC调用。最初的uthread_end真正通过协程调度发动这些lambda内的RPC调用,并期待完结。 当然你能够借用这4个宏定义,以同步代码的写法,进行更自定义的并发拜访。 Server配置阐明 (xxx_server.conf) 本文系微信后盾团队,如有进犯,请分割咱们立刻删除 ...

August 31, 2021 · 1 min · jiezi

关于im:MySQL半同步复制的数据一致性探讨

MySQL是一个RDBMS(关系型数据库管理系统),由瑞典MySQL AB 公司开发,目前属于 Oracle 旗下产品。因为其体积小、速度快、领有成本低,尤其是开放源码这一特点,广受各大企业欢送,包含腾讯,阿里,百度,网易,Google,FaceBook等互联网巨头企业。随着互联网的高速倒退,互联网服务可用性变得越发重要,数据容灾也随之成为各企业的要害工作。在数据容灾中,数据库集群如何解决数据一致性也成为了各企业须要解决的问题。特地在一些新兴的金融服务中,MySQL也逐步成为其外围数据库,如何保障金钱的准确性则尤为重要。MySQL也从一开始的异步复制,到Google开发的半同步复制,到MySQL 5.7更新的lossless半同步复制,始终在优化集群的数据一致性问题。尽管MySQL始终在优化数据的一致性问题,但问题仍然存在,使得各大企业纷纷各自设计一套MySQL补丁来保证数据统一。腾讯数平的TDSQL,腾讯微信的PhxSQL,阿里的AliSQL,网易的InnoSQL等设计都是为了保证数据一致性。MySQL5.7公布的lossless半同步,尽管声称zero loss,解决了5.6版本中有可能呈现的data lost问题,但其数据一致性仍未齐全解决。对于MySQL的具体介绍能够参考MySQL官网PPT http://www.slideshare.net/and...MySQL半同步复制的问题 图1 MySql半同步流程 图1形容了MySQL的Binlog半同步过程。Wait ACK是半同步的关键步骤,Master把Binlog发给Slave之后,须要期待Slave的ACK。Master直到胜利收到ACK之后,才执行Engine Commit把数据长久化到Storage。具体细节可参考:http://my-replication-life.bl... MySQL启动时,Wait ACK过程会被跳过,导致Engine Commit会被间接执行。具体细节请参考:https://jira.mariadb.org/brow... 上面对MySQL的数据在Master和Slave之间是否能保障统一进行简略剖析。探讨均基于各机器数据最终是否统一来开展。上面的剖析只针对半同步复制,且假如半同步失败后不会进化成异步复制。 场景1:Master失常工作Master的数据复制到Slave,Slave与Master保持数据统一。场景2:Master Crash且不切换Master场景2.1Master曾经收到ACK,并执行Engine Commit。Slave与Master保持数据统一。场景2.2Master处于Wait ACK阶段,存在PendingBinlog(未执行Engine Commit的Binlog)。 图2 Master重启时执行EngineCommit,并把Binlog从新复制给Slave Master重启时执行EngineCommit。Slave从新连贯Master,Binlog从新开始复制,随后Slave数据和Master统一。如图2。 因而,在MySql5.7的状况下,场景2.2能保障Master和Slave之间的数据一致性。然而在MySQL5.6及之前的版本,场景2.2是不能保证数据一致性的,具体请参考:http://my-replication-life.bl... 场景3:Master Crash且切换Master场景3.1旧Master Crash时,曾经收到至多一台Slave的ACK并执行Engine Commit。数据已复制到至多一台Slave,该Slave与旧Master的数据保持一致。 场景3.2旧Master处于Wait ACK阶段时Crash,新Master被切换到了一台领有最新Binlog的Slave。场景3.2中,旧Master中的PendingBinlog存在两种场景。场景3.2.1旧Master Crash时Binlog发送失败,未复制给任何Slave。 图3 机器A重启Commit Transaction X。机器A/B数据不统一。 图4 机器B接管到事务X的重试申请(事务X’)且复制到机器A。 机器A/B数据可能不统一。 假如机器A为旧Master,执行事务X时,复制失败并Crash。随后机器B成为新Master。机器A重启时执行Engine Commit,事务X被Commit。此时机器A和机器B的数据一致性被毁坏。两台机器上数据可能不统一。如图3,图4。 数据不统一的起因是机器A在重启时对PendingBinlog执行Engine Commit。在切换了Master的状况下,只能通过回滚PendingBinlog解决。 MySQL半同步插件的维护者也提到了相似的想法:http://my-replication-life.bl... 场景3.2.2旧Master Crash时Binlog发送胜利,但还未执行Engine Commit。!图6 机器A重启马上执行Engine Commit,数据统一假如机器A为旧Master,执行事务X时在执行Commit前Crash,但机器B收到事务X。随后机器B成为新Master。机器A重启时对PendingBinlog执行Engine Commit,执行胜利后机器A的数据是机器B的子集。此时机器A可从机器B中拉取最新的数据。另外一台Slave机器C能够从这两台机器中任意拉取。从图6能够看出,机器A在呈现故障时,因为TransactionX曾经复制给其中一台Slave和重启时立即Commit Transaction X,使得该Slave和Master的数据能保障统一。!图7 两台机器呈现故障,Master切换可能会失落数据 上述探讨都是基于领有最新数据的Slave和Master不能一起呈现故障。当这两台机器一起呈现故障时,进行Master切换则会造成数据失落。如图7。 对于较小的集群(机器数目小于或者等于3),当呈现两台机器一起产生故障时,可认为集群已无奈提供服务(半同步复制无奈工作)。 对于较大的集群(机器数目大于3),当呈现两台机器一起产生故障,且无奈得悉该两台机器的数据状态时,该集群也无奈提供服务(无奈确认领有最新数据的Slave是否蕴含在故障机器中)。因而,对于较大的集群,通常减少半同步复制期待ACK的数目,使得呈现上述情况时,仍能进行Master切换(非故障机器中,存在领有最新数据的机器)。 减少期待ACK的数目,解决了数据失落的问题,但同时给数据回滚带来了难题。 ![8] 图8如图8。假如MySQL集群有5台机器,半同步复制须要期待2台Slave的ACK。机器A为旧Master,在执行Wait ACK阶段,机器B收到Binlog后,机器A和机器B同时Crash或者被隔离,导致Binlog复制失败。依据场景3.2.1的剖析,当机器C成为Master后,机器A和机器B在复原服务前须要对其进行数据回滚。但对Slave进行数据回滚较为艰难。且若回滚失败,则会呈现数据不统一。 对于较小的集群,回滚PendingBinlog比拟容易实现。但对于较大的集群,回滚PendingBinlog自身就是一个未解决的难题。 MySQL的Master切换问题 Master如何切换同时也是MySQL容灾中的一个难题。 一个简略的Master切换步骤: ...

August 31, 2021 · 1 min · jiezi

关于im:Paxos理论介绍1-朴素Paxos算法理论推导与证明

微信重磅开源生产级paxos类库PhxPaxos,本文向大家论述PhxPaxos的基石“奢侈Paxos”。这篇文章摘取局部我在微信外部对于Paxos的分享PPT,通过注解的形式尝试与大家说明确奢侈Paxos的实践证实。 为何要重点说奢侈的Paxos?集体认为这个才是Paxos的精华所在,也是所有Paxos相干算法的基石所在。另外本文将着重解说Paxos的算法推导过程,而不是运行过程。因为以在我学习算法的教训来看,推导过程对于把握一门算法至关重要,只有把握了实践推导过程,能力明确这个算法每一个步骤的含意。 这些PPT内容大部分都引自Lamport的论文 "The Part-Time Parliament" . 页1注解 这是PPT的题图,摆在两头的正是Paxos最为重要的三条束缚,把握这三条束缚,即可把握奢侈Paxos。 页2注解 在正式开始解说之前,心愿抛开所有对Paxos的开展,而回到最奢侈的Paxos。最奢侈的Paxos解决什么问题?这里举个例子:三个人别离只容许呆在不同的三个城市,他们手上有一张纸和一支笔,他们能够在纸上写下任何内容,然而,当他们停下他们的笔之后,咱们心愿三个人最初写下的内容都是一样的。 这个就是最奢侈的Paxos尝试解决的问题,确定一个值。临时千万别去想更多的货色,聚焦在确定一个值这么一个看似非常简单的事件身上。 页3注解 直入主题,提出一轮投票的定义。通过投票来决定一个提议,是一个十分原始的办法,也是十分显然的公理,这里不开展说。这里提议对应刚刚说到的这个值。这一页每个定义都要弄明确,因为上面会经常用到这些定义。比方你要记住,一轮投票会有一个编号标识他们,称之为Bbal。你还要了解汇合的意思,一轮投票汇合B概括了这一轮投票的所有参加人,投票编号,提议,以及投票状况等。 比拟难了解的Bqrm这里开展解释一下:一轮投票取得通过,必须有Bqrm的人进行了投票,这个Bqrm每次可能都是不同的汇合,然而它的特色是必定超过总体投票成员的半数,也就是咱们常说的多数派。 页4注解 很显然,一轮投票是解决不了一致性问题的,因为任意一个人都有可能去发动投票,而不能靠上帝去指定某个人去发动,所以必然会面临多轮投票带来的问题。这里提出多轮投票的定义。留神这个多轮投票汇合的定义是希腊字母Beta,一轮投票汇合是大写字母B,是不一样的。咱们心愿寻求办法解决多轮投票带来的抵触,从而去达到确定一个值的指标。 ! 页5注解 最重要的定义MaxVote的提出。要尝试解决多轮投票带来的抵触问题,必然要去建设多轮投票之间的分割,MaxVote是一个分割。 MaxVote通过给出一个编号,以及成员,能够在多轮投票外面找到这些成员小于这个编号的所有投票当中,最大编号的那个投票。而后咱们心愿用到这次投票对应的提议。仔细阅读样例表格外面的每个MaxVote,从而去了解这个定义。 页6注解 在提出了所有数学定义后,就能够去了解这最柔美的三个约束条件了。正是通过这三个束缚,使得多轮投票的抵触问题失去解决。 第一点很好了解,要求每轮投票的编号惟一。第二点要求任意两轮投票的Bqrm交加不为空,其实意思很明确,就是要求Bqrm超过半数的意思。第三点是解决抵触的关键所在,它强行束缚了每轮投票的提议,使得这轮投票的提议不与之前的产生抵触。艰深一点讲就是,一旦我发现在我之前曾经有人投过某个提议的票,那我就要用这个提议,并且是我之前最大编号的投票对应的提议,作为我这次的提议。 页7注解 这是在三个约束条件之下的多轮投票过程。重复浏览这两页,从而了解约束条件3。留神在约束条件下,提议内容的变动。 ! 页8注解 看似这个投票过程能够引出最终统一的提议内容,但严格的算法推导必然须要严格的证实。这里提出反证法。 页9注解 这一页已将证实过程进行简化,置信通过你们认真的斟酌,必定是能够搞明确的。留神表格外面的样例,当编号为2的这轮投票曾经通过后,又呈现了一轮编号为3的投票(2和3两头不可能存在一轮投票),提议跟之前的抵触。咱们通过推导得出这个状况是不存在的。 页10注解 后面只是提出MaxVote的定义,这里解释计算这个MaxVote的实际操作过程。其实就是咱们习用的轮询法,一一问呗。只有每次发动投票前,都想多数派的成员逐个询问它们比我以后这轮投票编号小的最大编号投票,即可取得整个汇合的MaxVote,从而确定以后这轮投票的提议。 页11注解 聪慧的读者可能早曾经发现问题了,咱们上文所说的多轮投票,仿佛编号都是严格递增的,然而现实情况齐全不是这样,事实的多轮投票往往都是乱序的,这个大家应该毫无疑问。那么在这种状况下,MaxVote的值可能是会错的。设想一下,在算出一个MaxVote(5,...)之后,才呈现一个编号比5小的投票,那么这个投票很有可能会影响到这个MaxVote的值。也就是一个先来后到的乱序问题。而如果MaxVote是错的,咱们的证实就生效了。 页12注解 为了满足这个束缚,咱们须要对MaxVote的计算过程进行束缚。 看过Paxos算法过程的,且是聪慧的读者,看完这页可能会想起,哦原来Prepare的Promise要求是这么来的。 页13注解 到这里算法曾经是十分欠缺了,剩下就是怎么将这个算法引申到计算机上,在计算机层面上提出算法的过程。大家能够看到理论的算法过程,很多角色都是与咱们刚刚形容的货色绝对应的。 页14注解 正式算法过程,也就是Lamport的论文 "Paxos Made Simple" 提出的。 我心愿大家再回头看这个算法过程时候,晓得每一步的含意,以及背地的实质。 页15注解 一个过程演示,这个就不多解释了。 结语 奢侈Paxos算法不容易,须要重复的斟酌,倡议有急躁的读者多看几遍,只有有急躁,必定是能够弄懂的。对于这个算法有什么用?如何去实现?请查看咱们的历史文章,外面有更多分享。 本文系微信后盾团队,如有进犯,请分割咱们立刻删除 github开源地址: https://github.com/tencent-we... OpenIMgithub开源地址: https://github.com/OpenIMSDK/... ...

August 31, 2021 · 1 min · jiezi

关于im:转载微信自研生产级paxos类库PhxPaxos实现原理介绍

微信重磅开源生产级paxos类库PhxPaxos,本文用科普的口气向大家介绍PhxPaxos背地的实现原理以及一些有意思的细节。前言 本文是一篇无需任何分布式以及paxos算法根底的人能够看懂的。题目次要有三个关键字,生产级,paxos,实现,涵盖了本文的重点。什么叫生产级,直译就是能用于生产线的,而非试验产品。生产级别领有超高的稳定性,不错的性能,能真正服务于用户的。paxos就不用说了,而实现,是本文最大的重点,本文将避开paxos算法实践与证实,直入实现细节,通知大家一个生产级别的paxos库背地的样子。为何要写这篇文章?paxos算法实践与证实不是更重要么?我几年前已经也读过Paxos论文,尽管大抵了解了算法的过程,然而在脑海中却无一个场景去构建这个算法,而后也就缓缓印象淡化以至于最近重读paxos论文的时候,感觉像是第一次读论文的样子。 在真正去实现了paxos之后,我才顿悟了这个问题。人们去了解一个实践或事务的时候,都会往这个实践或事物上套一个场景,而后在脑海里模仿而试图去懂得他。比方经典的Dijkstra算法,事实它并不只用于最短寻路,然而在学习这个算法的时候,最短寻路给咱们提供了一个很好的场景,能够让咱们更快的去了解它。 第一次读paxos论文,我不晓得它的利用场景,不晓得它是用来干什么的,也不晓得它怎么实现,然而这些往往就是一个根底,大神可能能够本人发明场景,然而更多的人都须要晓得这个场景,当你晓得后,了解算法将变得更为容易。 本文,将通知你paxos是什么,用来做什么,怎么应用它,如何工程化,如何做到生产级别,以及在工程上会遇到的问题与解决办法。文中将用尽量讲课形式的口气,以及尽量避免专业术语,力求把这么一件事能论述的更为艰深和简略易懂。 什么是paxos 一致性协定 Paxos是一个一致性协定。什么叫一致性?一致性有很多种,也从强到弱分了很多等级,如线性一致性,因果一致性,最终一致性等等。什么是统一?这里举个例子,三台机器,每台机器的磁盘存储为128个字节,如果三台机器这128个字节数据都完全相同,那么能够说这三台机器是磁盘数据是统一的,更为形象的说,就是多个正本确定同一个值,大家记录下来同一个值,那么就达到了一致性。 Paxos能达到什么样的一致性级别?这是一个较为简单的问题。因为一致性往往不取决与客观存在的事实,如3台机器尽管领有雷同的数据,然而数据的写入是一个过程,有工夫的先后,而更多的一致性取决于观察者,观察者看到的并未是最终的数据。这里就先不开展讲,先暂且认为paxos保障了写入的最终一致性。 为何说是一个协定而不是一个算法,能够这么了解,算法是设计进去服务于这个协定的,如同法律是协定,那么算法就是各种机构的执行者,使得法律的束缚能失去保障。 Paxos的协定其实很简略,就三条规定,我认为这三条规定也是paxos最精华的内容,各个执行者奋力的去爱护这个协定,使得这个协定的束缚失效,天然就失去了一致性。 分布式环境 为何要设计出这么一套协定,其余协定不行么。如最容易想到的,一个值A,往3台机器都写一次,这样一套简略的协定,能不能达到一致性的成果?这里就波及到另外一个概念,Paxos一致性协定是在特定的环境下才须要的,这个特定的环境称为异步通信环境。而恰好,简直所有的分布式环境都是异步通信环境,在计算机领域面对的问题,十分须要Paxos来解决。 异步通信环境指的是音讯在网络传输过程中,可能产生失落,提早,乱序景象。在这种环境下,下面提到的三写协定就变得很鸡肋了。音讯乱序是一个十分顽劣的问题,这个问题导致大部分协定在分布式环境下都无奈保障一致性,而导致这个问题的根本原因是网络包无法控制超时,一个网络包能够在网络的各种设施交换机等停留数天,甚至数周之久,而在这段时间内任意收回的一个包,都会跟之前收回的包产生乱序景象。无法控制超时的起因更多是因为时钟的关系,各种设施以及交换机时钟都有可能错乱,无奈判断一个包的真正达到工夫。 异步通信环境并非只有paxos能解决一致性问题,经典的两阶段提交也能达到同样的成果,然而分布式环境外面,除了音讯网络传输的顽劣环境,还有另外一个让人痛心疾首的,就是机器的当机,甚至永恒失联。在这种状况下,两阶段提交将无奈实现一个一致性的写入,而paxos,只有多数派机器存活就能实现写入,并保障一致性。 至此,总结一下paxos就是一个在异步通信环境,并容忍在只有多数派机器存活的状况下,依然能实现一个一致性写入的协定。 提议者 后面讲了这么多都是协定协定,在分布式环境当中,协定作用就是每台机器都要表演一个角色,这个角色严格遵守这个协定去解决音讯。在paxos论文外面这个角色称之为Acceptor,这个很好了解。大家其实更关怀另外一个问题,到底谁去发动写入申请,论文外面介绍发动写入申请的角色为提议者,称之为Proposer,Proposer也是严格遵守paxos协定,通过与各个Acceptor的协同工作,去实现一个值的写入。在paxos外面,Proposer和Acceptor是最重要的两个角色。 Paxos是用来干什么的 确定一个值 既然说到写入数据,到底怎么去写?写一次还是写屡次,还是其余?这也是我一开始苦恼的问题,置信很多人都会很苦恼。 这里先要明确一个问题,paxos到底在为谁服务?更确定来说是到底在为什么数据服务?还是引下面的例子,paxos就是为这128个字节的数据服务,paxos并不关怀里面有多少个提议者,写入了多少数据,写入的数据是不是一样的,paxos只会跟你说,我确定了一个值,当这个值被确定之后,也就是这128个字节被确定了之后,无论里面写入什么,这个值都不会扭转再扭转了,而且三台机确定的值必定是一样的。 说到这预计必定会有人蒙逼了,说实话我过后也蒙逼了,我要实现一个存储服务啊,我要写入各种各样的数据啊,你给我确定这么一个值,能有啥用?但先抛开这些疑难,大家先要明确这么一个概念,paxos就是用来确定一个值用的,而且大家这里就先晓得这么个事件就能够了,具体paxos协定是怎么的,怎么通过协定外面三条规定来取得这样的成果的,怎么证实的等等实践上的货色,都举荐去大家去看看论文,然而先看完本文再看,会失去另外的成果。 如下图,有三台机器(前面为了简化问题,不做特地阐明都是以三台机器作为解说例子),每台机器上运行这Acceptor来恪守paxos协定,每台机器的Acceptor为本人的一份Data数据服务,能够有任意多个Proposer。当paxos协定声称一个值被确定(Chosen)后,那么Data数据就会被确定,并且永远不会被扭转。 Proposer只须要与多数派的Acceptor交互,即可实现一个值的确定,但一旦这个值被确定下来后,无论Proposer再发动任何值的写入,Data数据都不会再被批改。Chosen value即是被确定的值,永远不会被批改。 确定多个值 对咱们来说,确定一个值,并且当一个值确定后是永远不能被批改的,很显著这个利用价值是很低的。尽管我都甚至还不晓得确定一个值能用来干嘛,但如果咱们能有方法能确定很多个值,那必定会比一个值有用得多。咱们先来看下怎么去确定多个值。 上文提到一个三个Acceptor和Proposer各自恪守paxos协定,协同工作最终实现一个值的确定。这里先定义一个概念,Proposer,各个Acceptor,所服务的Data独特形成了一个大的汇合,这个汇合所运行的paxos算法最终目标是确定一个值,咱们这里称这个汇合为一个paxos instance,即一个paxos实例。 一个实例能够确定一个值,那么多个实例天然能够确定多个值,很简略的模型就能够构建进去,只有咱们同时运行着多个实例,那么咱们就能实现确定多个值的指标。 这里强调一点,每个实例必须是齐全独立,互不干涉的。意思就是说Acceptor不能去批改其余实例的Data数据,Proposer同样也不能逾越实例去与其余实例的Acceptor交互。 如下图,三台机器每台机器运行两个实例,每个实例独立运作,最终会产生两个确定的值。这里两个理论能够扩大成任意多个。 至此,实例(Instance)以成为了我当初介绍paxos的一个根本单元,一个实例确定一个值,多个实例确定多个值,但各个实例独立,互不干涉。 然而比拟遗憾的一点,确定多个值,依然对咱们没有太大的帮忙,因为外面最可恨的一点是,当一个值被确定后,就永远无奈被批改了,这是咱们不能承受的。大部分的存储服务可能都须要有一个批改的性能。 有序的确定多个值 咱们须要转换一下切入点,兴许咱们须要paxos确定的值,并不一定是咱们真正看到的数据。咱们察看大部分存储系统,如LevelDB,都是以AppendLog的模式,确定一个操作系列,而后须要复原存储的时候都能够通过这个操作系列来复原,而这个操作系列,正是确定之后就永远不会被批改的。到这曾经很恍然大悟了,只有咱们通过paxos实现一个多机统一的有序的操作系列,那么通过这个操作系列的演进,可实现的货色就很有设想空间了,存储服务必然不是问题。 如何利用paxos有序的确定多个值?上文咱们晓得能够通过运行多个实例来实现确定多个值,但为了达到程序的成果,须要增强一下束缚。 首先给实例一个编号,定义为i,i从0开始,只增不减,由本机器生成,不依赖网络。其次,咱们保障一台机器任一时刻只能有一个实例在工作,这时候Proposer往该机器的写申请都会被当前工作的实例受理。最初,当编号为i的实例获知曾经确定好一个值之后,这个实例将会被销毁,进而产生一个编号为i+1的实例。 基于这三个束缚,每台机器的多个实例都是一个间断递增编号的有序系列,而基于paxos的保障,同一个编号的实例,确定的值都是统一的,那么三台机都取得了一个有序的多个值。 上面联合一个图示来具体阐明一下这个运作过程以及存在什么异常情况以及异常情况下的解决形式。 图中A,B,C代表三个机器,红色代表曾经被销毁的实例,依据上文束缚,最大的实例就是以后正在工作的实例。A机器当前工作的实例编号是6,B机是5,而C机是3。为何会呈现这种工作实例不一样的状况?首先解释一下C机的状况,因为paxos只要求多数派存活即可实现一个值的确定,所以假如C呈现当机或者音讯失落提早等,都会使得本人不晓得3-5编号的实例曾经被确定好值了。而B机比A机落后一个实例,是因为B机刚刚参加实现实例5的值的确定,然而他并不知道这个值被确定了。下面的状况与其说是异常情况,也能够说是失常的状况,因为在分布式环境,产生这种事件是很失常的。 上面剖析一下基于图示状态的对于C机的写入是如何工作的。C机实例3解决一个新的写入,依据paxos协定的保障,因为实例3曾经确定好一个值了,所以无论写入什么值,都不会扭转原来的值,所以这时候C机实例3发动一轮paxos算法的时候就能够获知实例3真正确定的值,从而跳到实例4。但在工程实现上这个事件能够更为简化,上文提到,各个实例是独立,互不干涉的,也就是A机的实例6,B机的实例5都不会去理睬C机实例3收回的音讯,那么C机实例3这个写入是无奈失去多数派响应的,天然无奈写入胜利。 再剖析一下A机的写入,同样实例6无奈取得多数派的响应,同样无奈写入胜利。同样如果B机实例5有写入,也是写入失败的后果,那如何使得能持续写入,实例编号能持续增长呢?这里引出下一个章节。 实例的对齐(Learn) **** 上文说到每个实例外面都有一个Acceptor的角色,这里再减少一个角色称之为Learner,顾名思义就是找他人学习,她回去询问别的机器的雷同编号的实例,如果这个实例曾经被销毁了,那阐明值曾经确定好了,间接把这个值拉回来写到以后实例外面,而后编号增长跳到下一个实例再持续询问,如此重复,直到以后实例编号增长到与其余机器统一。 因为束缚外面保障仅当一个实例获知到一个确定的值之后,能力编号增长开始新的实例,那么换句话说,只有编号比当前工作实例小的实例(已销毁的),他的值都是曾经确定好的。所以这些值并不需要再通过paxos来确定了,而是间接由Learner间接学习失去即可。 如上图,B机的实例5是间接由Learner从A机学到的,而C机的实例3-5都是从B机学到的,这样大家就全副走到了实例6,这时候实例6承受的写申请就能持续工作上来。 如何利用paxos 状态机 **** 一个有序的确定的值,也就是日志,能够通过定义日志的语义进行重放的操作,那么这个日志是怎么跟paxos联合起来的呢?咱们利用paxos确定有序的多个值这个特点,再加上这里引入的一个状态机的概念,联合起来实现一个真正有工程意义的零碎。 状态机这个名词大家都不生疏,一个状态机必然波及到一个状态转移,而paxos的每个实例,就是状态转移的输出,因为每台机器的实例编号都是间断有序增长的,而每个实例确定的值是一样的,那么能够保障的是,各台机器的状态机输出是完全一致的。依据状态机的实践,只有初始状态统一,输出统一,那么引出的最终状态也是统一的。而这个状态,是有有限的设想空间,你能够用来实现十分多的货色。 如下图这个例子是一个状态机联合paxos实现了一个具备多机统一的KV零碎。 实例0-3的值都曾经被确定,通过这4个值最终引出(b, ‘jeremy’)这个状态,而各台机器实例系列都是统一的,所以大家的状态都一样,尽管引出状态的工夫有先后,但确定的实例系列确定的值引出确定的状态。 下图例子通知大家Proposer,Acceptor,Learner,State machine是如何协同工作的。 一个申请发给Proposer,Proposer与雷同实例编号为x的Acceptor协同工作,共同完成一值的确定,之后将这个值作为状态机的输出,产生状态转移,最终返回状态转移后果给发动请求者。 工程化 咱们须要多个角色尽量在一起 **** 上文提到一个实例,须要有Proposer和Acceptor两个角色协同工作,另外还要加以Learner进行辅助,到了利用方面又退出了State machine,这外面势必会有很多状态须要共享。如一个Proposer必须于Acceptor处于雷同的实例能力工作,那么Proposer也就必须晓得当前工作的实例是什么,又如State machine必须晓得实例的chosen value是啥,而chosen value是存储于Acceptor治理的Data数据中的。在概念上,这些角色能够通过任意的通信形式进行状态共享,但真正去实现,咱们都会尽量基于简略,高性能登程,个别咱们都会将这些角色同时交融在一个机器,一个过程外面。 ...

August 30, 2021 · 1 min · jiezi

关于im:OpenIM服务发现和负载均衡golang插件gRPC接入etcdv3

etcd简介etcd是CoreOS团队于2013年6月发动的开源我的项目,它的指标是构建一个高可用的分布式键值(key-value)数据库。etcd外部采纳raft协定作为一致性算法,etcd基于Go语言实现。 etcd作为服务发现零碎,有以下的特点: 简略:装置配置简略,而且提供了HTTP API进行交互,应用也很简略平安:反对SSL证书验证疾速:依据官网提供的benchmark数据,单实例反对每秒2k+读操作牢靠:采纳raft算法,实现分布式系统数据的可用性和一致性etcd我的项目地址:https://github.com/coreos/etcd/ etcd典型利用场景-服务发现 etcd比拟多的利用场景是用于服务发现,服务发现(Service Discovery)要解决的是分布式系统中最常见的问题之一,即在同一个分布式集群中的过程或服务如何能力找到对方并建设连贯。 从实质上说,服务发现就是要理解集群中是否有过程在监听upd或者tcp端口,并且通过名字就能够进行查找和链接。 要解决服务发现的问题,须要上面三大支柱,缺一不可。 一个强一致性、高可用的服务存储目录。基于Ralf算法的etcd天生就是这样一个强一致性、高可用的服务存储目录。 一种注册服务和衰弱服务健康状况的机制。用户能够在etcd中注册服务,并且对注册的服务配置key TTL,定时放弃服务的心跳以达到监控衰弱状态的成果。 一种查找和连贯服务的机制。通过在etcd指定的主题下注册的服务业能在对应的主题下查找到。为了确保连贯,咱们能够在每个服务机器上都部署一个proxy模式的etcd,这样就能够确保拜访etcd集群的服务都可能相互连贯。 gRPC简介gRPC是谷歌开源的一款跨平台、高性能的RPC框架。gRPC是一个古代的开源高性能RPC框架,能够在任何环境下运行。在理论开发过程中,次要应用它来进行后端微服务的开发。 在gRPC中,客户端应用程序能够像本地对象那样间接调用另一台计算机上的服务器应用程序上的办法,从而更容易创立分布式应用程序和服务。与许多RPC零碎一样,gRPC基于定义服务的思维,能够通过设置参数和返回类型来近程调用办法。在服务端,实现这个接口并运行gRPC服务器来解决客户端调用。客户端提供的办法(客户端与服务端的办法雷同)。 如图所示,gRPC客户端和服务端能够在各种环境中运行和互相通信,并且能够用gRPC反对的任何语言编写。因而,能够用Go语言创立一个gRPC服务器,同时供PHP客户端和Android客户端等多个客户端调用,从而冲破开发语言的限度。 服务注册:register.go`` /etcdAddr separated by commasfunc RegisterEtcd(schema, etcdAddr, myHost string, myPort int, serviceName string, ttl int) error { cli, err := clientv3.New(clientv3.Config{ Endpoints: strings.Split(etcdAddr, ","), }) fmt.Println("RegisterEtcd") if err != nil { // return fmt.Errorf("grpclb: create clientv3 client failed: %v", err) return fmt.Errorf("create etcd clientv3 client failed, errmsg:%v, etcd addr:%s", err, etcdAddr) } //lease ctx, cancel := context.WithCancel(context.Background()) resp, err := cli.Grant(ctx, int64(ttl)) if err != nil { return fmt.Errorf("grant failed") } // schema:///serviceName/ip:port ->ip:port serviceValue := net.JoinHostPort(myHost, strconv.Itoa(myPort)) serviceKey := GetPrefix(schema, serviceName) + serviceValue //set key->value if _, err := cli.Put(ctx, serviceKey, serviceValue, clientv3.WithLease(resp.ID)); err != nil { return fmt.Errorf("put failed, errmsg:%v, key:%s, value:%s", err, serviceKey, serviceValue) } //keepalive kresp, err := cli.KeepAlive(ctx, resp.ID) if err != nil { return fmt.Errorf("keepalive faild, errmsg:%v, lease id:%d", err, resp.ID) } go func() { FLOOP: for { select { case _, ok := <-kresp: if ok == true { } else { break FLOOP } } } }() rEtcd = &RegEtcd{ctx: ctx, cli: cli, cancel: cancel, key: serviceKey} return nil}grpc模块在启动时调用RegisterEtcd注册,并定时lease ...

August 27, 2021 · 4 min · jiezi

关于im:原创开源OpenIM轻量高效实时可靠低成本的消息模型

1、内容概述一套残缺IM零碎中,除开根本的业务设计,音讯模型的设计是其中最为要害的一环,它关系到整个IM零碎的可靠性、高效性、稳定性,因而须要设计一套正当的消息传递收发机制以承载IM的各种需要,OpenIM联合具体的业务场景,提炼出IM后端的重要接口,并通过反复推敲,验证,设计出了本人的一套通信协议OMTP,协定中每个字段尽量的缩小冗余,使其精简高效、最大限度的满足现有的业务需要并可能反对业务的程度拓展,同时为了达到音讯的实时牢靠与高效,音讯模型也通过了精心设计。 (1)音讯的实时性:音讯的实时性是考验IM零碎的重要规范,传统的IM通过http长短轮询的形式来模仿实时音讯,存在“实时性盲区”,所以OpenIM也同样应用了HTML5的Websocket技术,Websocket是真正的全双工双向通信技术,可能实现服务器被动推送音讯到客户端,实现真正的实时双向通信(服务器告诉客户端有信息达到,客户端随时向服务器发送新音讯),一次连贯,随时都能够应用,不必像轮询技术中一直应用http申请,这样升高了服务器的负载,并缩小一些高频无用的申请。 (2)音讯的可靠性:音讯的可靠性,是指音讯的不失落,不反复,因为网络环境的各种简单状况,包含数据在达到客户端后,数据须要进行各种解析与解决,包含写入db,存入cache,UI的各种展示等等,而且还包含客户端的各种异常情况,当我的项目越宏大时候,应用层呈现谬误的可能性会更高,都可能会造成音讯的失落,通常为了使得音讯更为牢靠,业务层通常采取的计划有:1、在应用层减少ACK音讯,这种计划能够了解为模仿TCP的流程去保障音讯的可靠性,server发送数据达到客户端后,客户端处理完毕(通常是保证数据曾经存入db中)会向server发送一条ACK音讯确认本人曾经收到了音讯,当server收到ACK音讯后才确认音讯曾经胜利交付,否则就会应用某种策略进行音讯的重发;这个计划也会呈现如果ACK音讯发送后,server出于网络的起因没有胜利收到,而后server进行了重发消息,客户端会反复的收到了这条音讯,所以客户端须要进行去重解决。2、音讯减少一条序列号,为每条音讯调配一个音讯ID(OpenIM便是应用的这种计划),对于每个用户而言,在本人的音讯收件箱中,音讯的收取队列中seq应该是间断的,如果客户端层面,或者网络起因造成音讯没可能实时的达到,客户端能够在应用层减少逻辑采取某种策略通过seq比照,本地的seq和服务器的seq之间的差值去拉取没能正确交付到客户端的音讯,这种计划相比于ACK音讯来说,不必每一条音讯都须要server断定ACK来确认音讯是否曾经达到客户端,音讯的获取获取逻辑更加简略,然而音讯的拉取依赖于客户端,如果pull拉取频率过于高,其流量的损耗的也是不低的,所以OpenIM在客户端断网重连,音讯拉取策略上做了优化解决以确保音讯拉取频率在一个适合的范畴。 (3)兼具轻量、高效、低成本:OpenIM设计之初,便是以“所有从简”的准则登程,去除了一些不必要、不合理的设计,使得整个音讯通道更加简洁,零碎更加轻量级,零碎设计应用的是微服务架构形式,每个节点都可能反对集群部署,各个节点之间通过注册核心互连,在集群模式下可能主动的进行负载平衡与流量切换,并且音讯通道提供了给应用服务器回调接口,不便应用服务器对于音讯的管制,不便其余利用可能高效的接入OpenIM并拓展本人的业务,因为OpenIM是一个开源零碎,任何企业和集体都能收费获取源码,并自行构建OpenIM服务,疾速搭建公有IM服务器,并迅速让IM性能集成到本人的零碎中,数据自我把握,不必依赖于别人,相比云服务商,极大的升高了获取IM能力所须要的老本。 服务器层面从音讯发送到接管的流程大抵能够分为两个阶段: 客户端发送音讯到服务器阶段服务器传输音讯到客户端阶段2、音讯发送阶段模型图:OpenIM音讯的发送阶段,也就是音讯服务的上行阶段,流程如下:(1)次要由客户端被动发送音讯到服务器,目前所反对的应用层协定次要是http和websocket,为了应答不同客户端的需要,咱们在音讯网关接口中别离设置了https和wss的接口来作为OpenIM的网关接入层。(2)接口层依赖于ETCD集群(用于RPC服务的注册和发现)调用RPC独特调用音讯处理单元,处理单元处理完毕后将音讯放入MQ中,并返回给客户端相应后果,音讯只有胜利落入MQ中,就能够视为发送胜利,音讯发送的可靠性依赖于MQ集群。(3)值得一提的是,在音讯的处理单元,咱们减少了内部调用接口(由具体的业务服务器实现的http接口),能够实现业务服务器对音讯的管制解决,例如音讯的禁止发送,过滤等具体的业务需要,这种音讯的回调业务服务器的设定不便使用者能够依据本人的业务需要对音讯进行解决,设立在服务器回调这种形式也更加安全可靠,可见在OpenIM的上行音讯发送阶段,咱们通过ACK、集群化部署等形式,来保障音讯的发送中数据传输的可靠性。3、音讯传输阶段模型图:OpenIM音讯的传输阶段(包含将音讯交付到接收者客户端或发送者的其余客户端),即是音讯服务的上行阶段,流程如下:(1)上游将拆分解决后的音讯放入MQ中,传输阶段次要的工作,是从MQ中拿到音讯,并进行长久化存储以及交付push模块。(2)在音讯的存储方面,咱们所应用的是收件箱模式,即每个用户都带一个信箱,一条音讯发送后,发送者和接收者的信箱都会减少一条信息,这种写扩散的的形式将写进行了放大,它的长处是,对于客户端而言,无论是间接接收数据,还是被动拉取数据逻辑都比较简单,间接获取本人收件箱外面所有的音讯,咱们次要应用Redis存储音讯的seq(每一条音讯对于接收者和发送者都会产生一个惟一的递增的音讯序列号),应用MongoDB存储历史音讯(用户间接拉取的音讯),MySQL存储全量的历史音讯(漫游音讯)。(3)音讯异步交付长久层后,通过RPC调用push模块,为了减少音讯的可靠性,咱们应用了RPC+MQ双向保障音讯推送的达到,当RPC间接调用失败后,会通过MQ直达音讯达到push模块。(4)push模块次要的工作是负责音讯的传递(包含接收者多端收到音讯,以及发送者多端的音讯同步等),次要是通过将从RPC接口中或MQ中获取的音讯通过接入网关应用websocket进行音讯的在线推送,当用户不在线时,调用三方的离线推送确保音讯可能达到客户端。在本文中次要论述了OpenIM的特点和在服务器层面上的音讯模型架构设计,不便开发者对后端音讯的整个流程有一个清晰的意识,在后续的文章中,咱们会持续解说OpenIM客户端层面的音讯的架构设计。 源链接:OpenIM官网OpenIM官方论坛 更多技术文章:开源OpenIM:高性能、可伸缩、易扩大的即时通讯架构 【OpenIM原创】简略轻松入门 一文解说WebRTC实现1对1音视频通信原理

August 27, 2021 · 1 min · jiezi

关于im:OpenIM转载万亿级调用系统微信序列号生成器架构设计及演变

微信在立项之初,就已确立了利用数据版本号实现终端与后盾的数据增量同步机制,确保发消息时音讯牢靠送达对方手机,防止了大量潜在的家庭纠纷。时至今日,微信曾经走过第五个年头,这套同步机制依然在音讯收发、朋友圈告诉、好友数据更新等须要数据同步的中央施展着外围的作用。而在这同步机制的背地,须要一个高可用、高牢靠的序列号生成器来产生同步数据用的版本号。这个序列号生成器咱们称之为seqsvr,目前曾经倒退为一个每天万亿级调用的重量级零碎,其中每次申请序列号平时调用耗时1ms,99.9%的调用耗时小于3ms,服务部署于数百台4核CPU服务器上。本文会重点介绍seqsvr的架构核心思想,以及seqsvr随着业务量疾速上涨所做的架构演变。 背景微信服务器端为每一份须要与客户端同步的数据(例如音讯)都会赋予一个惟一的、递增的序列号(后文称为sequence),作为这份数据的版本号。在客户端与服务器端同步的时候,客户端会带上曾经同步上来数据的最大版本号,后盾会依据客户端最大版本号与服务器端的最大版本号,计算出须要同步的增量数据,返回给客户端。这样不仅保障了客户端与服务器端的数据同步的可靠性,同时也大幅缩小了同步时的冗余数据。这里不必乐观锁机制来生成版本号,而是应用了一个独立的seqsvr来解决序列号操作,一方面因为业务有大量的sequence查问需要——查问曾经调配进来的最初一个sequence,而基于seqsvr的查问操作能够做到十分轻量级,防止对存储层的大量IO查问操作;另一方面微信用户的不同品种的数据存在不同的Key-Value零碎中,应用对立的序列号有助于防止反复开发,同时业务逻辑能够很不便地判断一个用户的各类数据是否有更新。 从seqsvr申请的、用作数据版本号的sequence,具备两种根本的性质: 递增的64位整型变量每个用户都有本人独立的64位sequence空间举个例子,小明以后申请的sequence为100,那么他下一次申请的sequence,可能为101,也可能是110,总之肯定大于之前申请的100。而小红呢,她的sequence与小明的sequence是独立开的,如果她以后申请到的sequence为50,而后期间不论小明申请多少次sequence怎么折腾,都不会影响到她下一次申请到的值(很可能是51)。这里用了每个用户独立的64位sequence的体系,而不是用一个全局的64位(或更高位)sequence,很大起因是全局惟一的sequence会有十分重大的申请互斥问题,不容易去实现一个高性能高牢靠的架构。对微信业务来说,每个用户独立的64位sequence空间曾经满足业务要求。目前sequence用在终端与后盾的数据同步外,同时也宽泛用于微信后盾逻辑层的根底数据一致性cache中,大幅缩小逻辑层对存储层的拜访。尽管一个用于终端——后盾数据同步,一个用于后盾cache的一致性保障,场景大不相同。但咱们仔细分析就会发现,两个场景都是利用sequence牢靠递增的性质来实现数据的一致性保障,这就要求咱们的seqsvr保障调配进来的sequence是稳固递增的,一旦呈现回退必然导致各种数据错乱、音讯隐没;另外,这两个场景都十分广泛,咱们在应用微信的时候会人不知;鬼不觉地对应到这两个场景:小明给小红发消息、小红拉黑小明、小明发一条失恋状态的朋友圈,一次简略的离别背地可能申请了无数次sequence。微信目前领有数亿的沉闷用户,每时每刻都会有海量sequence申请,这对seqsvr的设计也是个极大的挑战。那么,既要sequence牢靠递增,又要能顶住海量的拜访,要如何设计seqsvr的架构?咱们先从seqsvr的架构原型说起。 架构原型不思考seqsvr的具体架构的话,它应该是一个微小的64位数组,而咱们每一个微信用户,都在这个大数组里独占一格8bytes的空间,这个格子就放着用户曾经调配进来的最初一个sequence:cur_seq。每个用户来申请sequence的时候,只须要将用户的cur_seq+=1,保留回数组,并返回给用户。图1. 小明申请了一个sequence,返回101 预调配中间层任何一件看起来很简略的事,在海量的访问量下都会变得不简略。前文提到,seqsvr须要保障调配进来的sequence递增(数据牢靠),还须要满足海量的访问量(每天靠近万亿级别的拜访)。满足数据牢靠的话,咱们很容易想到把数据长久化到硬盘,然而依照目前每秒千万级的访问量(~10^7 QPS),根本没有任何硬盘零碎能扛住。后盾架构设计很多时候是一门对于衡量的哲学,针对不同的场景去思考能不能升高某方面的要求,以换取其它方面的晋升。认真思考咱们的需要,咱们只要求递增,并没有要求间断,也就是说呈现一大段跳跃是容许的(例如调配出的sequence序列:1,2,3,10,100,101)。于是咱们实现了一个简略优雅的策略: 内存中贮存最近一个调配进来的sequence:cur_seq,以及调配下限:max_seq调配sequence时,将cur_seq++,同时与调配下限max_seq比拟:如果cur_seq > max_seq,将调配下限晋升一个步长max_seq += step,并长久化max_seq重启时,读出长久化的max_seq,赋值给cur_seq图2. 小明、小红、小白都各自申请了一个sequence,但只有小白的max_seq减少了步长100这样通过减少一个预调配sequence的中间层,在保障sequence不回退的前提下,大幅地晋升了调配sequence的性能。理论利用中每次晋升的步长为10000,那么长久化的硬盘IO次数从之前~10^7 QPS升高到~10^3 QPS,处于可承受范畴。在失常运作时调配进来的sequence是程序递增的,只有在机器重启后,第一次调配的sequence会产生一个比拟大的跳跃,跳跃大小取决于步长大小。 分号段共享存储申请带来的硬盘IO问题解决了,能够反对服务安稳运行,但该模型还是存在一个问题:重启时要读取大量的max_seq数据加载到内存中。咱们能够简略计算下,以目前uid(用户惟一ID)下限2^32个、一个max_seq 8bytes的空间,数据大小一共为32GB,从硬盘加载须要不少工夫。另一方面,出于数据可靠性的思考,必然须要一个牢靠存储系统来保留max_seq数据,重启时通过网络从该牢靠存储系统加载数据。如果max_seq数据过大的话,会导致重启时在数据传输破费大量工夫,造成一段时间不可服务。为了解决这个问题,咱们引入号段Section的概念,uid相邻的一段用户属于一个号段,而同个号段内的用户共享一个max_seq,这样大幅缩小了max_seq数据的大小,同时也升高了IO次数。图3. 小明、小红、小白属于同个Section,他们共用一个max_seq。在每个人都申请一个sequence的时候,只有小白冲破了max_seq下限,须要更新max_seq并长久化 目前seqsvr一个Section蕴含10万个uid,max_seq数据只有300+KB,为咱们实现从牢靠存储系统读取max_seq数据重启打下基础。 工程实现工程实现在下面两个策略上做了一些调整,次要是出于数据可靠性及劫难隔离思考 把存储层和缓存中间层分成两个模块StoreSvr及AllocSvr。StoreSvr为存储层,利用了多机NRW策略来保证数据长久化后不失落;AllocSvr则是缓存中间层,部署于多台机器,每台AllocSvr负责若干号段的sequence调配,摊派海量的sequence申请申请。整个零碎又按uid范畴进行分Set,每个Set都是一个残缺的、独立的StoreSvr+AllocSvr子系统。分Set设计目标是为了做劫难隔离,一个Set呈现故障只会影响该Set内的用户,而不会影响到其它用户。图4. 原型架构图容灾设计接下来咱们会介绍seqsvr的容灾架构。咱们晓得,后盾零碎绝大部分状况下并没有一种惟一的、完满的解决方案,同样的需要在不同的环境背景下甚至有可能演化出两种截然不同的架构。既然架构是多变的,那纯正讲架构的意义并不是特地大,期间也会讲下seqsvr容灾设计时的一些思考和衡量,心愿对大家有所帮忙。seqsvr的容灾模型在五年中进行过一次比拟大的重构,晋升了可用性、机器利用率等方面。其中不论是重构前还是重构后的架构,seqsvr始终遵循着两条架构设计准则: 放弃本身架构简略防止对外部模块的强依赖这两点都是基于seqsvr可靠性思考的,毕竟seqsvr是一个与整个微信服务端失常运行非亲非故的模块。依照咱们对这个世界的意识,零碎的复杂度往往是跟可靠性成反比的,想得到一个牢靠的零碎一个关键点就是要把它做简略。置信大家身边都有一些这样的例子,设计方案里有很多高大上、简单的货色,同时也总能看到他们在默默地填一些高大上的坑。当然简略的零碎不意味着粗制滥造,咱们要做的是理出最外围的点,而后在满足这些外围点的根底上,针对性地提出一个足够简略的解决方案。 那么,seqsvr最外围的点是什么呢?每个uid的sequence申请要递增不回退。这里咱们发现,如果seqsvr满足这么一个束缚:任意时刻任意uid有且仅有一台AllocSvr提供服务,就能够比拟容易地实现sequence递增不回退的要求。图5. 两台AllocSvr服务同个uid造成sequence回退。Client读取到的sequence序列为101、201、102 但也因为这个束缚,多台AllocSvr同时服务同一个号段的多主机模型在这里就不实用了。咱们只能采纳单点服务的模式,当某台AllocSvr产生服务不可用时,将该机服务的uid段切换到其它机器来实现容灾。这里须要引入一个仲裁服务,探测AllocSvr的服务状态,决定每个uid段由哪台AllocSvr加载。出于可靠性的思考,仲裁模块并不间接操作AllocSvr,而是将加载配置写到StoreSvr长久化,而后AllocSvr定期拜访StoreSvr读取最新的加载配置,决定本人的加载状态。图6. 号段迁徙示意。通过更新加载配置把0~2号段从AllocSvrA迁徙到AllocSvrB同时,为了防止失联AllocSvr提供谬误的服务,返回脏数据,AllocSvr须要跟StoreSvr放弃租约。这个租约机制由以下两个条件组成: 租约生效:AllocSvr N秒内无奈从StoreSvr读取加载配置时,AllocSvr进行服务租约失效:AllocSvr读取到新的加载配置后,立刻卸载须要卸载的号段,须要加载的新号段期待N秒后提供服务图7. 租约机制。AllocSvrB严格保障在AllocSvrA进行服务后提供服务这两个条件保障了切换时,新AllocSvr必定在旧AllocSvr下线后才开始提供服务。但这种租约机制也会造成切换的号段存在小段时间的不可服务,不过因为微信后盾逻辑层存在重试机制及异步重试队列,小段时间的不可服务是用户无感知的,而且呈现租约生效、切换是小概率事件,整体上是能够承受的。到此讲了AllocSvr容灾切换的基本原理,接下来会介绍整个seqsvr架构容灾架构的演变 容灾1.0架构:主备容灾最后版本的seqsvr采纳了主机+冷备机容灾模式:全量的uid空间平均分成N个Section,间断的若干个Section组成了一个Set,每个Set都有一主一备两台AllocSvr。失常状况下只有主机提供服务;在主机出故障时,仲裁服务切换主备,原来的主机下线变成备机,原备机变成主机后加载uid号段提供服务。图8. 容灾1.0架构:主备容灾可能看到前文的叙述,有些同学曾经想到这种容灾架构。一主机一备机的模型设计简略,并且具备不错的可用性——毕竟主备两台机器同时不可用的概率极低,置信很多后盾零碎也采纳了相似的容灾策略。设计衡量主备容灾存在一些显著的缺点,比方备机闲置导致有一半的闲暇机器;比方主备切换的时候,备机在霎时要承受主机所有的申请,容易导致备机过载。既然一主一备容灾存在这样的问题,为什么一开始还要采纳这种容灾模型?事实上,架构的抉择往往跟过后的背景无关,seqsvr诞生于微信倒退初期,也正是微信疾速扩张的时候,抉择一主一备容灾模型是出于以下的思考: 架构简略,能够疾速开发机器数少,机器冗余不是次要问题Client端更新AllocSvr的路由状态很容易实现前两点好懂,人力、机器都不如工夫贵重。而第三点比拟有意思,上面开展讲下微信后盾绝大部分模块应用了一个自研的RPC框架,seqsvr也不例外。在这个RPC框架里,调用端读取本地机器的client配置文件,决定去哪台服务端调用。这种模型对于无状态的服务端,是很好用的,也很不便实现容灾。咱们能够在client配置文件外面写“对于号段x,能够去SvrA、SvrB、SvrC三台机器的任意一台拜访”,实现三主机容灾。 但在seqsvr里,AllocSvr是预调配中间层,并不是无状态的。而后面咱们提到,AllocSvr加载哪些uid号段,是由保留在StoreSvr的加载配置决定的。那么这时候就难堪了,业务想要申请某个uid的sequence,Client端其实并不分明具体去哪台AllocSvr拜访,client配置文件只会跟它说“AllocSvrA、AllocSvrB…这堆机器的某一台会有你想要的sequence”。换句话讲,原来负责提供服务的AllocSvrA故障,仲裁服务决定由AllocSvrC来代替AllocSvrA提供服务,Client要如何获知这个路由信息的变更? 这时候如果咱们的AllocSvr采纳了主备容灾模型的话,事件就变得简略多了。咱们能够在client配置文件里写:对于某个uid号段,要么是AllocSvrA加载,要么是AllocSvrB加载。Client端发动申请时,只管Client端并不分明AllocSvrA和AllocSvrB哪一台真正加载了指标uid号段,然而Client端能够先尝试给其中任意一台AllocSvr发申请,就算这次申请了谬误的AllocSvr,那么就晓得另外一台是正确的AllocSvr,再发动一次申请即可。 也就是说,对于主备容灾模型,最多也只会节约一次的试探申请来确定AllocSvr的服务状态,额定耗费少,编码也简略。可是,如果Svr端采纳了其它简单的容灾策略,那么基于动态配置的框架就很难去确定Svr端的服务状态:Svr产生状态变更,Client端无奈确定应该向哪台Svr发动申请。这也是为什么一开始抉择了主备容灾的起因之一。 主备容灾的缺点在咱们的理论经营中,容灾1.0架构存在两个重大的有余: 扩容、缩容十分麻烦一个Set的主备机都过载,无奈应用其余Set的机器进行容灾在主备容灾中,Client和AllocSvr须要应用完全一致的配置文件。变更这个配置文件的时候,因为无奈实现在同一时间更新给所有的Client和AllocSvr,因而须要非常复杂的人工操作来保障变更的正确性(包含须要应用iptables来做申请转发,具体的详情这里不做开展)。对于第二个问题,常见的办法是用一致性Hash算法代替主备,一个Set有多台机器,过载机器的申请被摊派到多台机器,容灾成果会更好。在seqsvr中应用相似一致性Hash的容灾策略也是可行的,只有Client端与仲裁服务都应用齐全一样的一致性Hash算法,这样Client端能够启发式地去尝试,直到找到正确的AllocSvr。 例如对于某个uid,仲裁服务会优先把它调配到AllocSvrA,如果AllocSvrA挂掉则调配到AllocSvrB,再不行调配到AllocSvrC。那么Client在拜访AllocSvr时,依照AllocSvrA -> AllocSvrB -> AllocSvrC的程序去拜访,也能实现容灾的目标。但这种办法依然没有克服后面主备容灾面临的配置文件变更的问题,经营起来也很麻烦。 容灾2.0架构:嵌入式路由表容灾最初咱们另辟蹊径,采纳了一种不同的思路:既然Client端与AllocSvr存在路由状态不统一的问题,那么让AllocSvr把以后的路由状态传递给Client端,突破之前只能依据本地Client配置文件做路由决策的限度,从根本上解决这个问题。所以在2.0架构中,咱们把AllocSvr的路由状态嵌入到Client申请sequence的响应包中,在不带来额定的资源耗费的状况下,实现了Client端与AllocSvr之间的路由状态统一。具体实现计划如下:seqsvr所有模块应用了对立的路由表,形容了uid号段到AllocSvr的全映射。这份路由表由仲裁服务依据AllocSvr的服务状态生成,写到StoreSvr中,由AllocSvr当作租约读出,最初在业务返回包里旁路给Client端。图9. 容灾2.0架构:动静号段迁徙容灾把路由表嵌入到申请响应包看似很简略的架构变动,却是整个seqsvr容灾架构的技术奇点。利用它解决了路由状态不统一的问题后,能够实现一些以前不容易实现的个性。例如灵便的容灾策略,让所有机器都互为备机,在机器故障时,把故障机上的号段平均地迁徙到其它可用的AllocSvr上;还能够依据AllocSvr的负载状况,进行负载平衡,无效缓解AllocSvr申请不均的问题,大幅晋升机器使用率。 另外在经营上也失去了大幅简化。之前对机器进行运维操作有着繁冗的操作步骤,而新架构只须要更新路由即可轻松实现上线、下线、替换机器,不须要关怀配置文件不统一的问题,防止了一些因为人工误操作引发的故障。图10. 机器故障号段迁徙 路由同步优化把路由表嵌入到取sequence的申请响应包中,那么会引入一个相似“先有鸡还是先有蛋”的哲学命题:没有路由表,怎么晓得去哪台AllocSvr取路由表?另外,取sequence是一个超高频的申请,如何防止嵌入路由表带来的带宽耗费?这里通过在Client端内存缓存路由表以及路由版本号来解决,申请步骤如下: Client依据本地共享内存缓存的路由表,抉择对应的AllocSvr;如果路由表不存在,随机抉择一台AllocSvr对选中的AllocSvr发动申请,申请带上本地路由表的版本号AllocSvr收到申请,除了解决sequence逻辑外,判断Client带上版本号是否最新,如果是旧版则在响应包中附上最新的路由表Client收到响应包,除了解决sequence逻辑外,判断响应包是否带有新路由表。如果有,更新本地路由表,并决策是否返回第1步重试基于以上的申请步骤,在本地路由表生效的时候,应用大量的重试便能够拉到正确的路由,失常提供服务。 总结到此把seqsvr的架构设计和演变根本讲完了,正是如此简略优雅的模型,为微信的其它模块提供了一种简略牢靠的一致性解决方案,撑持着微信五年来的高速倒退,置信在可预感的将来依然会施展着重要的作用。 本文系微信后盾团队,如有进犯,请分割咱们立刻删除咱们的官网及论坛:OpenIM官网OpenIM官方论坛

August 26, 2021 · 1 min · jiezi

关于im:OpenIM原创简单轻松入门-一文讲解WebRTC实现1对1音视频通信原理

什么是 WebRTC ?WebRTC(Web Real-Time Communication)是 Google于2010以6829万美元从 Global IP Solutions 公司购买,并于2011年将其开源,旨在建设一个互联网浏览器间的实时通信的平台,让 WebRTC技术成为 H5规范之一。咱们看官网(https://webrtc.org)的介绍 其中: Web Real-Time Communications (WEBRTC) W3C 组织:定义浏览器 API。Real-Time Communication in Web-browsers (RTCWEB) IETF 规范组织:定义其所需的协定,数据,安全性等伎俩。简略来说,WebRTC 是一个能够在 Web 应用程序中实现音频,视频和数据的实时通信的开源我的项目。在实时通信中,音视频的采集和解决是一个很简单的过程。比方音视频流的编解码、降噪和回声打消等,然而在 WebRTC 中,这所有都交由浏览器的底层封装来实现。咱们能够间接拿到优化后的媒体流,而后将其输入到本地屏幕和扬声器,或者转发给其对等端。 点对点音视频的难点抛开低提早、流畅性、回声打消和海量并发这些难点不讲,单纯从性能来看,买通通信单方的两端,让彼此能失常视频及通话,次要存在两个问题: (1)网络买通问题--无公网IP无奈间接通信当今互联网到处存在着一些中间件(MIddleBoxes),如NAT和防火墙,导致两个(不在同一内网)中的客户端无奈间接通信。这些问题即使是到了IPV6时代也会存在,因为即便不须要NAT,但还有其余中间件如防火墙阻挡了链接的建设。 当今部署的中间件大多都是在C/S架构上设计的,其中绝对隐匿的客户机被动向周知的服务端(领有动态IP地址和DNS名称)发动链接申请。大多数中间件实现了一种非对称的通信模型,即内网中的主机能够初始化对外的链接,而外网的主机却不能初始化对内网的链接,除非通过中间件管理员非凡配置。在中间件为常见的NAPT的状况下,内网中的客户端没有独自的公网IP地址,而是通过NAPT转换,和其余同一内网用户共享一个公网IP。这种内网主机暗藏在中间件后的不可拜访性对于一些客户端软件如浏览器来说并不是一个问题,因为其只须要初始化对外的链接,从某方面来看反而还对隐衷爱护有益处。然而在P2P利用中,内网主机(客户端)须要对另外的终端(Peer)间接建设链接,然而发起者和响应者可能在不同的中间件前面,两者都没有公网IP地址。而内部对NAT公网IP和端口被动的链接或数据都会因内网未申请被抛弃掉。对于WebRTC来说,首先要解决的是如果逾越NAT实现内网主机间接通信的问题。 (2)媒体格式编码问题--媒体格式编码多样不对立对于须要音视频通信的单方,彼此要理解对方反对的媒体格式能力失常地对流媒体编解码。比方,Peer­A端可反对VP8、H264多种编码格局,而Peer­B端反对VP9、H264,要保障二端都正确的编解码,最简略的方法就是取它们的交加H264。有一个专门的协定称为SDP(Session Description Protoco),可用于形容上述这类信息,在WebRTC中,参加视频通信的单方必须先替换SDP信息,这样单方能力知根知底,而替换SDP的过程,也称为“媒体协商” SDP(Session Description Protocol) 是一种会话形容协定,基于文本,其自身并不属于传输协定,须要依赖其它的传输协定(比方 SIP 和 HTTP)来替换必要的媒体信息,用于两个会话实体之间的媒体协商。SDP(会话形容协定)定义了一个规范,用于定义两个(通常)端与端之间媒体(通常是流媒体)替换的参数。IETF已将其公布为RFC 4566。SDP通常嵌入或封装在另一个协定中,最宽泛应用的应用程序位于大多数IP电话应用程序的SIP协定外部。简略地说,SDP协定是媒体端到端对其接管标准和能力的申明;典型的申明会通知咱们: (1)哪个IP地址筹备好接管传入的媒体流 (2)哪个端口号正在侦听传入的媒体流 (3)端点心愿接管的媒体类型(通常是音频) (4)端点心愿在哪个协定中替换信息(通常为RTP) (5)端点可能解码的压缩编码(编解码器) 在一个典型的会话设置过程中,咱们会看到两个端点参加一个会话,其中每个端点发送一个SDP以告诉另一个端点其标准和性能。SDP自身不提供任何媒体,但仅限于协商一组兼容的媒体替换参数;媒体流自身由不同的通道和协定解决。 一个 SDP 的握手由一个 offer 和一个 answer 组成 WebRTC通话原理点对点的单方为了实现实时音视频通信, WebRTC须要解决媒体协商和网络协商问题,这里要引入信令服务器(Signaling Server)和STUN server Signaling Server须要通信的单方之间建设WebRTC连贯须要一个信令服务器来实现单方通过网络进行连贯。信令服务器的作用是作为一个中间人帮忙单方在尽可能少的裸露隐衷的状况下建设连贯。WebRTC并没有提供信令传递机制,信令的传递和替换须要服务器参加,这个角色就是信令服务器。WebRTC信令指建设、管制和终止通信会话的过程以及业务自身的需要来看,须要替换几个信息:媒体信息,网络信息,具体业务。 一、媒体信息须要媒体数据来确定呼叫者和被呼叫者共有的编解码器和媒体类型。如果尝试启动通信会话的端具备不同的分辨率和编解码器配置,则会话不太可能胜利。通过应用会话形容协定(SDP)格局的提供和应答在对等方之间替换媒体配置信息的信令,这些信息是通过SDP协定形容进去,通过信令服务器直达的。 二、网络信息两个WebRTC客户端如何发现对方的?通过信令服务器交互单方在Internet上的地位(IP地址和端口),以便呼叫者能够找到被呼叫者。 三、具体业务会话管制信息确定何时初始化、敞开和批改通信会话,比方退出房间,来到房间,禁言,媒体流订阅公布等性能,须要信令服务器来管制。 ...

August 12, 2021 · 1 min · jiezi

关于im:开源OpenIM高性能可伸缩易扩展的即时通讯架构

网上有很多对于IM的教程和技术博文,有亿级用户的IM架构,有各种浅谈原创自研IM架构,也有微信技术团队分享的技术文章,有些开发者想依据这些材料自研IM。现实很饱满,事实很骨感,最初做进去的产品很难达到商用规范。事实上,很多架构没有通过海量用户的考验,当然咱们也不会评判某种架构的好坏,如果开发者希图依据网上教程做出一个商用的IM,可能有点过于乐观了。本文次要从我集体角度深度分析100%开源的OpenIM架构。当然,世界上没有最完满的架构,只有最合适的架构,也没有所谓的通用计划,不同的解决方案都有其优缺点,只有最满足业务的零碎才是一个好的零碎。而且,在无限的人力、物力,综合思考工夫老本,通常须要做出很多衡量。咱们OpenIM的设计初衷,充分考虑了中小企业的需要,轻量级部署,同时也反对集群扩大,能反对几万用户,也能轻松扩大到上亿用户,是一个可信赖的开源我的项目。 IM零碎技术挑战可靠性IM音讯零碎的可靠性,通常就是指音讯投递的可靠性,即咱们常常听到的“音讯必达”,通常用音讯的不失落和不反复两个技术指标来示意。确保音讯被发送后,能被接收者收到。因为网络环境的复杂性,以及用户在线的不确定性,音讯的可靠性(不失落、不反复)无疑是IM零碎的外围指标,也是IM零碎实现中的难点之一。总体来说,IM零碎的音讯“可靠性”,通常就是指聊天音讯投递的可靠性(精确的说,这个“音讯”是狭义的,因为还存用户看不见的各种指令和告诉,包含但不限于进群退群告诉、好友增加告诉等,为了不便形容,统称“音讯”)。 从音讯发送者和接收者用户行为来讲,音讯“可靠性”应该分为以下几种状况: (1)发送失败,对于这种状况IM零碎必须要感知到,明确反馈发送方。如果此音讯没有发送胜利,发送方能够抉择重试或者稍后再试。 (2)发送胜利,如果接管方处在“在线”状态,应该立刻收到此音讯。如果接管方处在“离线”状态不能收到音讯,一旦上线则立即收到音讯。 (3)音讯不能反复,用数学术语示意:“有且仅有这条音讯”,如果反复了,可能表白的意思就变了。总之,一个商用 IM零碎,必须蕴含音讯“可靠性”逻辑,能力谈根本可用,这是IM零碎最根本也是最外围的逻辑。 有序性(一致性)IM零碎中,特地须要思考音讯时序问题,如果后发送的音讯先显示,可能重大扰乱聊天音讯所要表白的意义,会造成聊天语义不连贯,引起误会。音讯的时序性,也称为音讯收发一致性,次要指标是:保障聊天音讯的相对时序。IM零碎中音讯时序的一致性问题看似简略,实则是十分有难度的技术热点话题之一。为什么会呈现时序问题 1、分布式系统的呈现导致时序不统一。IM零碎模块泛滥,接入层、音讯逻辑层等、每层都分布式集群化,这些利用散布在不同的机器上,如何保障时序是个难点。2、网络传输提早导致时序不统一。不同用户发送的音讯达到服务器的延时差别较大,给音讯时序性带来挑战。 音讯时序是分布式系统架构设计中十分难的问题,一个分布式的IM零碎必须要解决这个问题,如何高效、低成本解决这个问题,是咱们OpenIM要思考的方向。 实时性实时性,即音讯实时达到接管方,如果用户在线,则实时可达,如果用户不在线,则登录时可达。因为网络稳定,以及挪动端操作系统对利用前后台切换的治理,如何实现用户连贯治理、音讯实时推送,推送失败的解决形式,客户端重连机制,音讯如何补齐等,都是须要IM零碎思考,同时要联合挪动端的特点,兼顾耗电量,网络,性能等。因为TCP开发稍微简单,晚期的基于HTTP短轮询、长轮询的低效的技术计划,也无奈达到实时性的要求。 扩展性一般来说互联网零碎的扩展性蕴含多个含意,咱们偏重解说对于IM音讯的扩展性。IM业务个性多,功能丰富,从聊天类型来看,分为:单聊、群聊,聊天室等;从音讯类型来看,分为:文本、图片、视频、地理位置、自定义音讯等;从音讯性能来看,分为:撤回、在线状态、对方正在输出、阅后即焚等;从告诉角度来看,分为:进群、退群、增加好友、验证好友等各种告诉。如何无效撑持、扩大性能,高效实现,是考验IM扩展性的一个方面,也是对系统架构设计能力的考验。为了更好地进步数据通道对业务撑持的扩展性,咱们独创了“所有皆音讯”的音讯模型,即通信单方产生的所有音讯、告诉,服务端以音讯对立解决,表演了音讯通道的角色,客户端针对不同音讯类型做不同的UI展现,完满解决了扩展性问题。 IM零碎术语以及本文档专有名词解释conversationId:会话Id,会话是指用户和用户之间,以及用户和群之间,进行通信后产生的关联。 userId:用户Id:注册应用IM的用户Id,从音讯的发送和接管来看有两个身份:发送者和接收者 sendId:音讯发送者Id receiverId :音讯接收者Id msg:音讯是指用户之间的沟通内容,个别指用户被动产生的。同时也包含用户看不见的各种指令和告诉,包含但不限于进群退群告诉、好友增加告诉等 inbox:用户收件箱,给某人发送音讯,实际上是往接收者“信箱”写入音讯,这个信箱就是收件箱 seq:用户收件箱中音讯序列号,分为local seq,和server seq,前者示意app本地音讯seq,后者示意服务端音讯seq,seq是间断且递增的。 conn:登录用户的连贯信息,用于音讯推送; MQ:音讯队列,个别用来解决利用解耦,异步音讯,流量削峰等问题,实现高性能,高可用,可伸缩和最终一致性架构,本文采纳kafka组件。 点击学习IM技术文章1. OpenIM官网2.基于Tablestore Timeline的IM(即时通讯)音讯零碎架构 - 架构篇 OpenIM的诞生随着挪动互联网的蓬勃发展, IM 作为一种通信能力,曾经成为互联网上的基础设施,也是许多 APP 不可或缺的性能。如何让每一个利用都具备IM性能,同时思考企业的接入老本、服务器资源以及最重要的数据安全性和私密性。自己从微信到职后,开办了开源OpenIM,是寰球首家100%开源、收费我的项目,并提供IMSDK,笼罩所有支流开发平台,iOS、Android、Flutter、react native、Windows、Linux、Unity、web、小程序等。 开源IM现状github 上 IM 开源我的项目不少,但开发者却难以使用,次要有几点起因(1)集体我的项目居多,但近几年都无人保护,遇到问题无人解决,企业商业化产品不敢冒险应用(2)大部分我的项目不是 IM 技术业余团队实现的,技术实力和技术架构存疑,也没有通过大我的项目和海量用户测验;(3)只开源服务端或者客户端,只开源某一端,须要开发者实现另外一端,研发老本同样不小,另外,开源我的项目大部分都是以聊天app模式开源,开发者如何把 IM 集成到本身 app 中,同样存在大量的批改和适配老本。(4)局部我的项目打着开源的旗号,社区版收费,但外围性能缺失,商业版免费。 云服务商的弊病IM 云服务商提供 IM SDK 和 API ,让开发者简略集成 IM 性能,当然这里也存在显著的问题(1)老本问题:企业每年额定领取上万乃至数十万的云服务费用,从长期来看是个不小的老本;(2)数据隐衷问题:企业的用户数据、聊天记录等外围数据托管在 IM 云服务商,如何保障客户的数据隐衷和安全性;(3)需要定制问题:IM 需要多样化,IM 性能只能由 IM 云服务商通过 SDK 的模式提供给大家应用,开发受限,所有性能都须要封装成接口;(4)捆绑问题:一旦应用 IM 云服务,造成捆绑关系,迁徙老本高,受制于人。 自研的难堪IM 是一个看起来门槛很低的我的项目,网上有很多所谓的 IM 开发教程,甚至很多毕业设计也是做一个 IM 零碎。因为这个误区的存在,很多企业盲目乐观组建 3-5 人的 IM 团队,历时一年半载,最初只实现了一个 demo 版本。因为架构设计不合理,demo 版本存在音讯失落、零碎异样等 bug,无奈达到商用的要求。IM零碎除了面临互联网业务零碎自身的挑战,还存在上文剖析的可靠性、时序性、扩展性等问题,所以,自研IM,对于中小企业来说,可能是最蹩脚的抉择。 ...

July 28, 2021 · 1 min · jiezi

关于im:即时通信-IM-产品怎么选-本文超详细解说马住

即时通信产品的抉择难题 即时通信产品越来越深入人心,开源凋谢的生态圈、先天的云化架构等泛滥益处吸引着越来越多的企业用户,市场诞生了泛滥业余的即时通信厂商和服务商。 企业的CIO们也开始启动即时通信产品的落地,然而在落地时间接面临的首要问题就是该抉择怎么样的厂商。明天这篇文章,咱们将为宽广企业客户进行选购教学——如何抉择合乎本身条件的即时通信 IM (下文简称“IM”)产品?本期文章咱们将就此展开讨论。 在确定厂商提供的产品服务 可能满足企业需要的前提下 咱们能够通过以下三个方面进行选型 一、看平台首选支流厂商:研发经验丰富、稳定性强、售后服务靠谱,而且更提供长期稳固的云通信服务商; 优选互联网基因:互联网公司本着疾速解决客户需要,针对需要产出技术服务和能力,因而抉择具备互联网基因的厂商更容易满足各行业客户。尽量选用出名、正规的厂商,同时要做到货比三家。 二、硬实力企业在搭建利用的时候,须要思考云通信服务是否能为企业提供集成的能力,从而让零碎可能不便的集成运行。这就须要企业在抉择厂商的时候,要思考指标厂商是否能与本人外部所开发的技术进行集成。 三、比价格最初,也是咱们整篇文章的重点,比价格。 目前,各云通信服务商的免费形式有所不同,不少客户在抉择产品时会有一些纳闷,到底哪家价格实惠?不焦急,接下来就让咱们扒一扒计费模式背地的机密。 市场上次要有以下两种计费形式: 计费1:预付费套餐包+超量服务费+增值服务费 预付费套餐包:蕴含大部分根底性能服务+收费DAU额度等; 超量服务费:超过收费 DAU 额度局部按量按月计费; 增值服务费:如需实现更高阶的需要,如缩短历史音讯存储时长、扩大单个群成员数下限等需额定领取性能费用。 特点:根底性能服务齐备,根本无需另外购买性能,一包即可满足所有需要,价格也相当划算。 计费2:按 DAU 耗费阶梯定价+增值服务费 按 DAU 耗费阶梯定价:不同的服务商对 DAU 的免费也是不同的。这里要特地留神DAU的计算形式,次要分为以下三种状况: 1:单个用户当日登录为一个 DAU ,同一个用户反复登录时,DAU 不累加; 2:单个用户当日屡次登录,会反复计算DAU; 3:单日用户登录了不同的终端,会反复计算 DAU。 ps:在这三种状况中咱们要特地关注,第二和第三种 DAU 计费状况,若 DAU 反复计算的话,费用是不是也会随之上涨,往往很多用户都会疏忽这点。 增值服务费和计费1雷同,如需实现更高阶的需要,需额定领取性能费用。 特点:灵便选购所需性能以及 DAU,自定义搭配。 大抵理解以上两种计费特色后,咱们该如何价比三家? 首先,咱们得牢记两个问句: (1)我预估的用量要花多少费用? (2)实现我的需要须要多少费用? 咱们用这两个问句来实操一把: 案例场景:客户C,应用场景电商直播。预估DAU是20000,须要缩短历史音讯存储时长有3个月。 当初有厂商A、厂商B两个抉择: 厂商A:预付费包2899,蕴含收费DAU额度10000,收费历史存储时长30天。 如想满足C客户的需要,除了购买套餐包以外, 还需缴纳套餐外DAU费用:10000 DAU /1000元; 缩短历史音讯时长的增值费用为:180天/1000元/月; 共计费用:2899+1000+1000=4899。 厂商B:无预付费套餐包,DAU依照梯度免费且同一用户反复登录时,DAU不去重。DAU 20000的价格是5000元/月; 存储时长180天价格为600元/月; 共计费用:5000+600=5600 这个案例中,价格获胜的是厂商A,比厂商B便宜了701。 综上,咱们发现厂商A更实惠,抉择购买预付费套餐包根本涵盖了所要的需要,一包即解决所有问题,不必再扩散购买所需性能,so easy! 当然,预估用量和性能需要看似简略,可是难题就在价格可太难算。为了解决价格能更通透且高深莫测,腾讯云即时通信 IM 为广大客户开发了专属的价格计算器。 ...

July 22, 2021 · 1 min · jiezi

关于im:如何在-Electron-上实现-IM-SDK-聊天消息全文检索

前言在 IM 场景的客户端需要上,基于本地数据的全文检索(Full-text search)扮演着重要的角色。所谓全文检索,就是要在大量文档中找到蕴含某个单词呈现地位的技术。在以往的关系型数据库中,只能通过 LIKE 来实现,这样有几个弊病: 无奈应用数据库索引,须要遍历全表,性能较差搜寻成果差,只能首尾位含糊匹配,无奈实现简单的搜寻需要无奈失去文档与搜寻条件的相关性网易云信 IM 的 iOS、安卓以及桌面端中都实现了基于 SQLite 等库的本地数据全文检索性能,然而在 Web 端和 Electron 上短少了这部分性能。在 Web 端,因为浏览器环境限度,能应用的本地存储数据库只有 IndexDB,暂不在探讨的范畴内。在 Electron 上,尽管也是内置了 Chromium 的内核,然而因为能够应用 Node.js 的能力,于是乎抉择的范畴就多了一些。 咱们先来具体看下该如何实现全文检索。 根底技术知识点要实现全文检索,离不开以下两个知识点: 倒排索引分词这两个技术是实现全文检索的技术以及难点,其实现的过程绝对比较复杂,再聊全文索引的实现前,咱们先来具体聊一下这两个技术的实现。 倒排索引先简略介绍下倒排索引,倒排索引的概念区别于正排索引: 正排索引:是以文档对象的惟一 ID 作为索引,以文档内容作为记录的构造倒排索引:是以文档内容中的单词作为索引,将蕴含该词的文档 ID 作为记录的构造 以倒排索引库 search-index 举个理论的例子。在网易云信的 IM 中,每条音讯对象都有 idClient 作为惟一 ID,接下来咱们输出「今天天气真好」,将其每个中文独自分词(分词的概念咱们在下文会具体分享),于是输出变成了「今」、「天」、「天」、「气」、「真」、「好」,再通过 search-index 的 PUT 办法将其写入库中,最初看下存储内容的构造: 如图所示,能够看到倒排索引的构造,key 是分词后的单个中文,value 是蕴含该中文音讯对象的 idClient 组成的数组。当然,search-index 除了以上这些内容,还有一些其余内容,例如 Weight、Count 以及正排的数据等,这些是为了排序、分页、按字段搜寻等性能而存在的,本文就不再细细开展了。 分词分词就是将原先一条音讯的内容,依据语义切分成多个单字或词句,思考到中文分词的成果以及须要在 Node 上运行,咱们抉择了 Nodejieba 作为根底分词库。以下是 jieba 分词的流程图: 以「去北京大学玩」为例,咱们抉择其中最为重要的几个模块剖析一下: 加载词典jieba 分词会在初始化时先加载词典,大抵内容如下: 构建前缀词典接下来会依据该词典构建前缀词典,构造如下: ...

June 8, 2021 · 2 min · jiezi

关于im:IM扫码登录技术专题三通俗易懂IM扫码登录功能详细原理一篇就够

本文援用了作者“大古同学”的“二维码扫码登录是什么原理”一文的次要内容,为了更好的了解和浏览,即时通讯网收录时有订正和改变,感激原作者的分享。 1、引言自从微信的PC端应用扫码登陆认证逻辑后,这种形式仿佛在越来越多的IM中看到(尽管我集体认为这种登录形式很酷,但并不不便,尤其手机不大身边的时候)。 ▲ 上图微信PC端的扫码登录界面最近刚好看到一个二维码的技术原理解说视频,正好借此机会将扫码登录的具体技术原理梳理并总结一下,不便自已回顾,也心愿能帮忙到想在IM里开发相似性能的同行们。 补充阐明:本文所波及的扫码登陆原理并不是仅仅针对IM零碎,同样实用于IM之外的其它零碎。 学习交换: 即时通讯/推送技术开发交换5群:215477170 [举荐]挪动端IM开发入门文章:《新手入门一篇就够:从零开发挪动端IM》开源IM框架源码:https://github.com/JackJiang2...(本文同步公布于:http://www.52im.net/thread-35... 2、专题目录本文是系列文章的第3篇,总目录如下: 《IM扫码登录技术专题(一):微信的扫码登录性能技术原理调试剖析》《IM扫码登录技术专题(二):市面支流的扫码登录技术原理调试剖析》《IM扫码登录技术专题(三):通俗易懂,IM扫码登录性能具体原理一篇就够》(* 本文)3、二维码登录的实质3.1 扫码登录平安吗?在2维码扫码登录的过程中,大家可能会有疑难:这二维码平安吗?会不会透露我的个人信息?我的im零碎敢不敢也搞一个扫码登录呢? 针对这些顾虑,咱们须要理解一下二维码扫码登录背地的技术和逻辑实质。 3.2 扫码登录的技术实质二维码扫码登录实质上也是一种登录认证形式。 既然是登录认证,要做的也就两件事件: 1)通知零碎我是谁;2)向零碎证实我是谁。举个理论的例子来了解一下: 比方账号密码登录:账号就是通知零碎我是谁, 明码就是向零碎证实我是谁;比方手机验证码登录:手机号就是通知零碎我是谁,验证码就是向零碎证实我是谁。那么扫码登录是怎么做到这两件事件的呢? 以微作的扫码登录为例:手机端利用扫PC端二维码,手机端确认后,账号就在PC端登录胜利了!这里,PC端登录的账号必定与手机端是同一个账号。不可能手机端登录的是账号A,而扫码登录当前,PC端登录的是账号B。 所以,第一件事件——“通知零碎我是谁”,是比较清楚的! PS:通过扫描二维码,把手机端的账号信息传递到PC端,至于具体是怎么传的,咱们前面再说。 第二件事件:“向零碎证实我是谁”。扫码登录过程中,用户并没有去输出明码,也没有输出验证码,或者其余什么码。那是怎么证实的呢? 有些同学会想到,是不是扫码过程中,把明码传到了PC端呢? 但这是不可能的。因为那样太不平安的,客户端也基本不会去存储明码。 咱们认真想一下,其实手机端APP它是曾经登录过的,就是说手机端是曾经通过登录认证。所说只有扫码确认是这个手机且是这个账号操作的,其实就能间接证实我谁。 4、意识二维码那么如何做扫码登陆的确认呢?咱们前面会具体阐明,在这之前咱们须要先认识一下二维码! 在意识二维码之前咱们先看一下一维码! ▲ 这就是一维码 所谓一维码,也就是条形码,条形码实际上就是一串数字,以平时生存中的商品为例,它下面的一维码存储的就是商品的编号。 二维码其实与条形码相似,只不过它存储的不肯定是数字,还能够是任何的字符串,你能够认为,它就是字符串的另外一种表现形式。 在搜索引擎中搜寻二维码,你能够找到很多在线生成二维码的工具网站,这些网站能够提供字符串与二维码之间互相转换的性能,比方 草料二维码网站。 ▲ 输出一段字符串就能生成二维码 在右边的输入框就能够输出你的内容,它能够是文本、网址,文件........。而后就能够生成代表它们的二维码。 ▲ 这是二维码(曾经将内容含糊解决) 你也能够把二维码上传,进行”解码“,而后就能够解析出二维码代表的含意。 5、传统零碎是如何登陆认证的?意识了二维码,咱们理解一下挪动互联网下的传统登录认证机制。 后面咱们说过,为了平安,手机端它是不会存储你的登录明码的。 然而在日常应用过程中,咱们应该会留神到,只有在你的利用下载下来后,第一次登录的时候,才须要进行一个账号密码的登录, 那之后呢 即便这个利用过程被杀掉,或者手机重启,都是不须要再次输出账号密码的,它能够主动登录。 其实这背地就是一套基于token的认证机制,咱们来看一下这套机制是怎么运行的。 如上图所示: 1)账号密码登录时,客户端会将设施信息一起传递给服务端;2)如果账号密码校验通过,服务端会把账号与设施进行一个绑定,存在一个数据结构中,这个数据结构中蕴含了账号ID、设施ID、设施类型等等。const token = { acountid: '账号ID', deviceid: '登录的设施ID', deviceType: '设施类型,如 iso,android,pc......', } 而后服务端会生成一个token,用它来映射数据结构,这个token其实就是一串有着非凡意义的字符串,它的意义就在于,通过它能够找到对应的账号与设施信息。 具体是: 1)客户端失去这个token后,须要进行一个本地保留,每次拜访零碎API都携带上token与设施信息;2)服务端就能够通过token找到与它绑定的账号与设施信息,而后把绑定的设施信息与客户端每次传来的设施信息进行比拟, 如果雷同,那么校验通过,返回AP接口响应数据, 如果不同,那就是校验不通过回绝拜访。从后面这个流程,咱们能够看到,客户端不会也没必要保留你的明码,相同,它是保留了token。 可能有些同学会想,这个token这么重要,万一被他人晓得了怎么办。 实际上:晓得了也没有影响, 因为设施信息是惟一的,只有你的设施信息他人不晓得, 他人拿其余设施来拜访,验证也是不通过的。 能够说,客户端登录的目标,就是取得属于本人的token。 限于篇幅,这方面的文章,能够具体读一下以下几篇: ...

May 10, 2021 · 1 min · jiezi

关于im:集成融云-IM-问题总结

最近我的项目里用到了 IM 相干能力,并且之前也有理解融云,所以间接就用了,上面本人总结一些注意事项,在这些点上花了一丢丢工夫,在此记录下 1、融云是通过他们本人的 AppKey 来隔离不同利用之间的音讯的,只有在一个 AppKey 的用户可互发音讯2、连贯融云的时候,须要一个 Token,这个 Token 是通过融云的 Server 获取的,并且只能通过本人的 Server 调用,否则有平安问题,调试时能够用他们开发者后盾提供的调试工具来获取 Token,写死在页面调试,这点很重要,就不必等后端接口了 3、历史音讯默认不存,须要独自开明,这个也是看到了错误码才了解,之前始终在推敲,咋没有最近聊过天的人列表 4、如果须要浏览器多个 Tab 同时连贯,须要独自开明,关上多个浏览器,之前的 Tab 连贯就断了,兴许要独自开明,不过开发环境收费,能够轻易造,哈哈 5、A 给 B 发消息,只须要晓得 B 的 Id 就能够发了,B 再上线就能够收到,模仿两个发消息,能够关上两个浏览器别离模仿 A 和 B 发送和接管音讯 6、A 给 B 发送音讯,A 的 targetId 是 B,B 的 targetId 是 A,音讯的发送人是 A,这个逻辑有点绕,简略了解为 A 的 targetId 是 B,B 的 targetId 是 A,音讯的发送人 Id 不变,我滴妈呀,有点像饶舌,来哼起来 哈哈哈~ 结束,尽管没啥逻辑,记录下,好忘性不如烂笔头,免得后续再用~ 有须要能够去官网查看更多内容: 官网主页:https://www.rongcloud.cn 文档主页:https://docs.rongcloud.cn/v4

March 18, 2021 · 1 min · jiezi

关于im:融云-IM-那些事儿

最近闲来无事在网上冲浪,看到关注公众号推送了一篇 《Zoom大火之后,这家国内公司也很值得关注啊》 的文章,看样子八成是融云的 经营稿(融云的敌人看到别打我...),不过不重要,重要的因为这篇文章的确让我对 IM 和 RTC 提起了浓重的趣味,因为疫情期间还没有到职 公司每天都用 Zoom,起初 Zoom 这家伙发表进行对中国提供服务后,鬼晓得老板是为了彰显爱国主义情节还是怕服务不稳固,老板果决切换为腾讯会议 到职后尽管用的少了,但偶然开个会啥的,也会用腾讯会议或者微信的音视频进行和搭档进行线上沟通,这么说来接触音视频 Saas 也有一段时间了 但对底层如何实现的通话无所不知,你晓得的,作为一个有谋求的码农,知其然必知其所以然,正赶上看了后面提到的文章,于是马上入手开始钻研融云的 IM 和 RTC,先从 IM 开始说起~ 我是从以下几步别离理解:官网、开发者后盾、开发文档 官网从官网失去了以下个信息: 产品分类: 1、IM + RTC: 之前在公司听共事说过融云做 IM,不晓得啥时候也做了 RTC ,还挺有意思,不晓得具体起因,集体了解兴许 IM 的天花板比拟低或者变现难,并且音视频在将来网络根底设置越来越好、流量越来越便宜、5G 的到来等种种因素,音视频还是很有前景的,才杀入 RTC 战场,分一杯羹2、反对平台: Android、iOS、Web、小程序、Electron、Flutter 支流平台都反对 反对四种部署形式: 1、私有云: 大家专用一个盘子,有点过来大通铺的赶脚,我要是胖我睡的面积就大,当然了我要是胖可能还挤到你,可能会有资源抢占的状况,不过这要看融云的预留冗余资源了2、专有云: 相比大通铺,这个就高级多了,相似单间,空间、卫浴均为独立,并且私密性比拟好 3、海内云: 海内大通铺,在线征询了下,海内用户也能间接用国内数据中心,预计他们本人的网络链路,具体起因没有再细问,毕竟临时也不必,不太好意思,我是一个腼腆的人儿 4、公有云: 相比单间,这就是本人盖房子了,融云提供设计图,并且找施工队给你独自盖一个琉璃大瓦房,但后续怎么保护没看到阐明,有可能和通用外包的维护费用相似,比方:每年维护费是合同款的 10%,费用是我本人 YY 的,不会用也没好意思去找他们人理解 目前正在搞的流动: 1、黑客马拉松:印象最深的银子,第一名给五万,我是看到晚要不肯定加入,这样能够补救一点到职期间经济损失,毕竟到职前薪资也一个月 xxx 呢(一不小心差点把工资说进去,万一媳妇看见小金库可就没有了.....慌的一批,哈哈哈)2、WICC:全名好长,寰球互联网通信云大会,不和寰球占点关系,都不好意说本人是互联网公司,哈哈,不过看他们也有海内节点,这么说也正当,地址不在北京,惋惜去不了,要不真的能够去 see see 3、凝听:这是一个收集倡议的零碎包含吐槽啥的,看样子还是比拟重视客户服务,在这样一个技术可疾速复制的时代,兴许客户服务等软技能还是挺重要的,尤其是 ToB 企业 其余: 1、其余的都是一些案例介绍,这些东各家公司一模一样,秀秀肌肉、吹吹牛啥的,就没多看,目前我不关注这块开发者后盾功能丰富: 进入后盾第一眼真的是功能丰富,看进去的确是积攒了很多性能,不过产品逻辑不是很好,有点无从下手,钻研了一会了解了调试工具 调试工具点个赞,把所有服务端的接口都做了可在线调试的 API,如果集成初期没有本人 Server 接口,齐全能够用这个来集成,十分不便,很惊喜小槽点 开发者后盾的界面略丑,看起来有点像智能手机和老人机的排版布局差别,虽说不影响应用吧,但作为一个有谋求的青年咋能对美不挑剔呢,不对,应该少年,不对不对,是青少年,文章暂停下,我先倒腾下措辞....(两个小时后,是少年,我还是从前那个少年,没有一丝丝扭转.....)开发文档文档分类倒是简略,IM、RTC、经营服务, 上面一一介绍下感触 1、IM: 不愧是做 IM 起家的 Paas 厂商,反对的能力的确很杰出,尤其聊天室的性能分外丰盛,在线和客服妹子聊说人数无下限,反对弹性扩所容2、RTC: 看完文档就能晓得在音视频积淀还有不够,为啥这么说,在文档投入精力肯定不够,或者资源在忙于其余更重要的事件未开始布局,后盾看了看公布的第一版音视频 SDK,是在去年三月份,和感觉还比拟像,霎时感觉本人像老司机一样,哈哈 ...

March 18, 2021 · 1 min · jiezi

关于im:融云-IM-SDK-发送语音消息

因为公司既有挪动端又有 web 端,所以在语音音讯这遇到了些小问题。解决的过程最近整顿了下也分享给大家作为参考。 遇到问题 web 端发送语音的问题。挪动端发送来的 VoiceMessage 在 web 端不晓得如何解决。解决办法 问题一 融云只负责发消息,不提供录制。所以这边本人找了些录制的插件,这里参考了一个小示例https://blog.csdn.net/qq_37310318/article/details/88312013 拿到后改了改实现了音频录制,批改了上传的逻辑,上传逻辑应用的融云的上传插件,参考的文档 https://docs.rongcloud.cn/v4/views/im/noui/guide/private/msgmanage/msgsend/web.html#FileMsg 挪动端共事说他们用的是融云的 IMKit,于是提工单问了下,融云的共事给解决办法。Android 枚举类型 /** 语音音讯类型*/public enum VoiceMessageType { /** 一般音质语音音讯*/ Ordinary, /** 高音质语音音讯*/ HighQuality} Android RongIM.getInstance().setVoiceMessageType(RongIM.VoiceMessageType.HighQuality); iOS [RCIMClient sharedRCIMClient].voiceMsgType = RCVoiceMessageTypeHighQuality; 把上上述办法在初始化 init 时设置下即可发送高清语音音讯。完满解决。 实现中参考的文献: web 实现语音录制:https://blog.csdn.net/qq_37310318/article/details/88312013 融云文档:https://docs.rongcloud.cn/v4/views/im/noui/guide/private/msgmanage/msgsend/web.html#FileMsg 融云官网:https://www.rongcloud.cn/

March 18, 2021 · 1 min · jiezi

关于im:关于融云-SDK-在使用-p8-证书的坎坷

新上的我的项目应用了融云的 IM SDK,但在我的项目集成 APNs 推送的时候,尝鲜应用了一下开发者后盾的 p8 证书,此文记录应用 p8 的辛酸史~ P8 简介苹果文档传送门 官网给出了这种更 "快" 的推送通道: Establishing a Token-Based Connection to APNs,并且这个生成的这个 key 能够实用于以后账户的所有 APP,为开发人员省了不少力量。福音啊~ 想想那一堆证书...... 脑阔痛! 辛酸史起因是这样的,在融云开发者后盾上传了 p8 之后,发现 debug 环境,始终无奈收到推送,在通过和融云提供的推送文档进行严格的比对之后,发现没故障啊~ 最初终于在融云开发人员的帮忙下找到了问题~,融云后盾目前阶段只反对生产环境~ OMG,我打你信不~ 区别p8 是能够同时反对生产和测试环境的,那么为什么融云收不到呢~ 让咱们大胆猜想一下: 之前基于证书进行校验的时候,一套证书是基于开发者后盾一个 AppKey 绑定的,那么我用了哪个 AppKey,后端就基于 AppKey 解析对应的证书,这样就能够发送到对应的 push 环境去了,那么问题来了?应用了 p8 之后,他怎么辨别呢? 我也不晓得~ 哈哈哈,但我猜想应该是没有解析都去走了生产环境,因为提醒我环境不匹配~ 苹果 APNs 服务传送门 Development server: api.sandbox.push.apple.com:443 Production server: api.push.apple.com:443 融云文档传送门

March 17, 2021 · 1 min · jiezi

关于im:融云-Flutter-IM-SDK-解析

最近筹备应用融云的 Flutter SDK,所以顺便记录一下。 融云 Flutter IM SDK 地址:传送门 融云的 Flutter SDK 是基于 融云 IMLib 层做的封装,封装了 IMLib 的局部接口提供给 Flutter 开发者应用。此文章只介绍了 Flutter 层做的一些操作。 目录构造 整体 SDK 的构造规规矩矩,核心内容参考红色箭头即可。 SDK 层蕴含 三个目录: android:此目录蕴含了和原生 SDK 交互的所有 Java 文件 ios:此目录蕴含了和原生 SDK 交互的所有 oc 文件 lib: 此目录为应用 dart 编写的 Flutter SDK 文件 其余目录: doc:次要是融云开发者提供的一些文档相干 example:是融云开发者基于此 SDK 提供的一个简略示例,整体较为简陋,且有轻微 bug,仅供参考 FunctionList.md 是融云开发者提供的一个性能清单, 大体如下: RongCloud IM Flutter SDK 性能清单 连贯初始化连贯断开连接连贯状态兼容 配置设置服务器地址( im 服务;文件服务) 会话获取会话列表,反对全量获取,分页获取获取单个会话删除指定会话 音讯以后仅反对 文本音讯,语音音讯,图片音讯,小视频音讯收发音讯(能够携带 pushContent)自定义音讯获取批量本地历史音讯获取单条本地历史音讯获取批量远端历史音讯插入音讯删除批量本地音讯获取未读数革除指定会话未读数 免打搅设置会话免打搅获取会话免打搅 会话置顶设置会话置顶备注:获取会话是能够获取到会话置顶状态 ...

March 17, 2021 · 1 min · jiezi

关于im:融云会话页面刷新不及时问题

我的项目用的融云 IMKit SDK,调试中发现收到音讯的时候,不刷新,上拉一下才会显示。排查办法是间接应用 SDK 的会话页面,排除是子类代码的问题,替换后发现还是有此问题。起初和技术人员沟通发现是应用了 RCIMClient 中的初始化接口,这样会影响 UI 刷新的。替换为 RCIM 的初始化办法,问题解决!心愿此文字能够帮忙到后续开发者! /*! 初始化融云SDK @param appKey 从融云开发者平台创立利用后获取到的App Key @discussion 您在应用融云SDK所有性能(包含显示SDK中或者继承于SDK的View)之前,您必须先调用此办法初始化SDK。 在App整个生命周期中,您只须要执行一次初始化。 @warning 如果您应用IMKit,请应用此办法初始化SDK; 如果您应用IMLib,请应用RCIMClient中的同名办法初始化,而不要应用此办法。 */ (void)initWithAppKey:(NSString *)appKey;情谊提醒融云官网:(www.rongcloud.cn)

March 17, 2021 · 1 min · jiezi

关于im:融云自定义消息不显示

我的项目用的融云,IMKit SDK(自带 UI),然而呈现一个问题,就是自定义音讯在会话页面刚收到的时候能显示,然而退出会话页面再进入就不显示了。十分的纳闷啊。查问了存储策略,编解码办法,都没有问题。起初提交工单,技术人员给了反馈才发现自己把音讯的注册放到了初始化 appkey 前边,而后人家融云写的很明确:应用融云SDK所有性能(包含显示SDK中或者继承于SDK的View)之前,您必须先调用此办法初始化 SDK。可见认真查看文档接口正文的重要性!! /*! 初始化融云SDK @param appKey 从融云开发者平台创立利用后获取到的App Key @discussion 您在应用融云SDK所有性能(包含显示SDK中或者继承于SDK的View)之前,您必须先调用此办法初始化SDK。 在App整个生命周期中,您只须要执行一次初始化。 @warning 如果您应用IMKit,请应用此办法初始化SDK; 如果您应用IMLib,请应用RCIMClient中的同名办法初始化,而不要应用此办法。 */ (void)initWithAppKey:(NSString *)appKey;融云(www.rongcloud.cn)

March 17, 2021 · 1 min · jiezi

关于im:如何利用融云-IMLib-来实现一个阅后即焚功能

场景我的项目须要在私聊中来实现一个阅后即焚的性能,即 A 用户给 B 用户发送音讯,B 用户在进入聊天页面查看之后 A 用户删除此音讯,B 用户开始进入倒计时,倒计时完结后,删除此音讯。 思考大体的梳理一下具体的逻辑 A -> BB 进入会话页面B 将此音讯开始倒计时告诉 A 我已进行浏览A 删除音讯从下面内容咱们来大体的设计一下咱们须要用户的技术 单例类自定义音讯,用来通知 A 我曾经开始浏览了,你删除吧一个用于保护阅后即焚音讯的治理类一个存储 A 给 B 发送的所有的阅后即焚的音讯的容器 A <k, v> k 为 targetid ,v 为 messageIDs一个存储每条阅后即焚音讯的容器 B <k,v> k 为 messageId, v 为以后音讯还剩的倒计时工夫。一个用来存储所有阅后即焚音讯的容器 C K:ID V:msg两个解决队列 一个解决工夫 一个解决音讯对外裸露接口 代理 接管方焚烧音讯的每秒倒计时告诉 接管方收到对方已浏览某条音讯的告诉详解初始化咱们的所有容器收到音讯,在适合的业务机会将此音讯退出到焚烧队列查问音讯是否曾经在焚烧队列如果不在,增加到 A B C容器执行倒计时倒计时操作 遍历 C 是否有音讯给发送方发送音讯,告诉我曾经开始焚烧 A 里的音讯了 并在 A 容器删除此会话发送方收到音讯发送告诉接管方遍历 B 容器,判断每条音讯是否到时如果音讯焚烧工夫到 在 A、B 容器删除,并触发代理如果没到工夫,就触发代理并批改 此音讯在 B 容器的时长。

March 17, 2021 · 1 min · jiezi

关于im:融云-IMKit-音频录制参数

场景: 应用融云自带的界面进行语音音讯的播放。本人进行音频录制。应用的融云的 RCHQMessage问题: 语音音讯 iOS 和 Android 不互通,接管到音讯之后无奈播放。解决方案: 通过与融云开发者的确认,应用时必须保障如下录制参数: iOS AVAudioRecorder 录制参数如下设置: AVFormatIDKey : @(kAudioFormatMPEG4AAC_HE),AVSampleRateKey : @(44100.0),AVNumberOfChannelsKey : @1,AVEncoderBitRateKey : @(16000) Android MediaRecorder 录制参数如下: setAudioSamplingRate(44100);setAudioEncodingBitRate(16000);setAudioChannels(1);setAudioSource(MediaRecorder.AudioSource.MIC);setOutputFormat(MediaRecorder.OutputFormat.MPEG_4);setAudioEncoder(MediaRecorder.AudioEncoder.HE_AAC); 其余一些内容的应用能够本人去官网文档搜寻: 融云文档:https://docs.rongcloud.cn/v4/

March 17, 2021 · 1 min · jiezi

关于im:唠一唠融云的消息补偿机制

最近我的项目发现了一个很诡异的景象,纵使删除了会话且革除了历史音讯,一旦卸载重装利用,之前删除的局部音讯又莫名其妙的从新收到且显示了,见鬼啦~????~,在“福尔摩斯·我”的周密排查下(提工单问了融云的技术支持????),假相只有一个。 假相:原来是因为开启了融云的“多设施音讯同步”服务,在卸载重装利用时,触发了该服务中的“音讯弥补”机制,默认会把当天收发过的音讯从新拉取回来。 如果既须要开明“多设施音讯同步”服务,又须要卸载重装利用时保障之前删除的会话和历史音讯不再显示,该如何解决呢? 计划: 删除会话且革除历史音讯向该会话发送一条不存储不计数的自定义音讯,作用是标识该会话曾经被革除卸载重装利用触发“音讯弥补”机制,除了收到之前收发过的音讯,也会收到标识该会话被革除的自定义音讯在接管到该自定义音讯时,对该会话再做一遍革除操作,也就是“删除会话且革除历史音讯”注: “音讯弥补”默认是当天,也能够批改这个工夫,具体能够征询融云 https://www.rongcloud.cn/ 顺便说一下,他们的技术支持服务还是挺到位的,根本都能失去绝对称心的回答,如果感觉问他们比拟麻烦,能够本人先在文档 https://docs.rongcloud.cn/v4/ 外面找找,说不定会有惊喜哟~

March 17, 2021 · 1 min · jiezi

关于im:给融云的输入框上方加个功能按钮怎么整

给输入框上方加个性能按钮,相似常用语或者抽奖啥的,是个挺广泛的需要,惋惜遍寻文档(https://docs.rongcloud.cn/v4/)无果,只能靠本人了,咱们来看看怎么做吧。 首先,咱们要先在聊天页面增加个属性,也就是须要性能按钮所在的 view @property (nonatomic, strong) UIView *needAddView; 再就是须要重写 viewWillAppear 生命周期函数,增加这个 needAddView,设置 UI 布局,保障进入页面时,needAddView 能够正确显示 (void)viewWillAppear:(BOOL)animated {[super viewWillAppear:animated];//初始化 needAddView,增加到 self.view 上,坐标 y = 输入框的 y 坐标 - needAddView 高度CGFloat needAddView_height = 50.f;CGFloat y = self.chatSessionInputBarControl.frame.origin.y - needAddView_height;self.needAddView = [[UIView alloc] initWithFrame:CGRectMake(0, y, self.conversationMessageCollectionView.frame.size.width, needAddView_height)];self.needAddView.backgroundColor = [UIColor blueColor];[self.view addSubview:self.needAddView]; //设置音讯内容 collectionView 的高度,要减去 needAddView 的高度,防止被遮挡。CGRect frame = self.conversationMessageCollectionView.frame;frame.size.height -= needAddView_height;self.conversationMessageCollectionView.frame = frame; } 最初须要依据输入框的地位变动,对 UI 布局做扭转 -(void)chatInputBar:(RCChatSessionInputBarControl *)chatInputBar shouldChangeFrame:(CGRect)frame { //切记要调用父类办法,保障 UI 布局显示正确 [super chatInputBar:chatInputBar shouldChangeFrame:frame]; ...

March 17, 2021 · 1 min · jiezi

关于im:如何隐藏融云输入框语音按钮

我的项目中应用了融云自带页面的 IMKit SDK,产品需要是不须要输入框处的语音按钮。发现 SDK 接口还是比拟弱小的,然而须要认真的查看 .h 文件 API 正文。间接应用聊天页面的 chatSessionInputBarControl 属性即可.它外部有接口能够设置输入框类型: 上代码: (void)viewDidLoad {[super viewDidLoad];[self.chatSessionInputBarControl setInputBarType:RCChatSessionInputBarControlDefaultTypestyle:RC_CHAT_INPUT_BAR_STYLE_CONTAINER_EXTENTION];}

March 16, 2021 · 1 min · jiezi

关于im:使用融云-IM-点击最近聊天记录时跳转到-自己的消息

有没有遇到过这样的问题,在最近聊天记录列表外面有 @ 你的音讯,点列表外面对应的记录,进入聊天页面当前,跳到了最新接管到的音讯,想要看 @ 本人的音讯,还得可劲儿的下来去找,应用体验不好,想要改善的话,往下看。 实现思路就是获取会话中 @ 本人的音讯,把这条音讯的工夫传给聊天页面,而后再跳转,就能够跳转到这条音讯了。 在 push 到会话页面之前,调 RCIMClient 类上面接口,获取 @ 本人的音讯/*! 获取会话中@揭示本人的音讯 @param conversationType   会话类型 @param targetId           指标会话ID @discussion 此办法从本地获取被@揭示的音讯(最多返回10条信息) @warning 应用 IMKit 留神在进入会话页背后调用,否则在进入会话革除未读数的接口 clearMessagesUnreadStatus: targetId: 以及 设置音讯接管状态接口 setMessageReceivedStatus:receivedStatus:会同步革除被提示信息状态。 */ (NSArray )getUnreadMentionedMessages:(RCConversationType)conversationType targetId:(NSString )targetId;遍历失去数组,找到本人想要跳转到的音讯,把音讯的 sentTime 传给要跳转的聊天页面,再 push 到聊天页面。/** 进入页面时定位的音讯的发送工夫 @discussion 用于音讯搜寻之后点击进入页面等场景 */@property (nonatomic, assign) long long locatedMessageSentTime; 示例代码 (void)onSelectedTableRow:(RCConversationModelType)conversationModelType conversationModel:(RCConversationModel )model atIndexPath:(NSIndexPath )indexPath {if (model.conversationType == ConversationType_GROUP) {NSArray *msgs = [[RCIMClient sharedRCIMClient] getUnreadMentionedMessages:model.conversationType targetId:model.targetId];if (msgs.count > 0) {RCMessage *msg = msgs[0];RCConversationViewController *vc = [[RCConversationViewController alloc] initWithConversationType:model.conversationType targetId:model.targetId];vc.locatedMessageSentTime = msg.sentTime;[self.navigationController pushViewController:vc animated:YES];}}} ...

March 16, 2021 · 1 min · jiezi

关于im:融云-IM-SDK-如何插入消息

应用融云 IMKit SDK 集成的时候,须要插入一条音讯,而后及时刷新 UI,然而集成完,因为对 SDK 不相熟,只有退出聊天页面再进来才会刷新进去。于是后盾提工单,技术大大给提供了计划,一语中的,解决了我的需要,非常感谢,特此记录,留给须要的敌人 //下述代码须要在聊天页子类调用, 因为 appendAndDisplayMessage 是聊天页的办法RCTextMessage *msg = [RCTextMessage messageWithContent:@"hello world"];RCMessage *insertMsg = [[RCIMClient sharedRCIMClient] insertOutgoingMessage:ConversationType_PRIVATE targetId:self.targetId sentStatus:SentStatus_SENT content:msg];[self appendAndDisplayMessage:insertMsg]; 想理解更多能够自行到融云官网查看 (https://www.rongcloud.cn/)

March 16, 2021 · 1 min · jiezi

关于im:Android-端如何添加自定义表情

实现步骤 1.新建 RongEmoticonTab 类继承 IEmoticonTab 。public class RongEmoticonTab implements IEmoticonTab { public RongEmoticonTab() { } @Override public Drawable obtainTabDrawable(final Context context) { return context.getResources().getDrawable(R.drawable.u1f603); } @Override public View obtainTabPager(Context context) { return view; } @Override public void onTableSelected(int i) { }} 2.在 obtainTabPager 中增加您想要展现在表情面板上的 view 。 @Override public View obtainTabPager(Context context) { View view = LayoutInflater.from(context).inflate(R.layout.view_emoji, null); RecyclerView rv = view.findViewById(R.id.recycler_view); //LinearLayoutManager是用来做列表布局,也就是单列的列表 GridLayoutManager mLayoutManager = new GridLayoutManager(context, 5, OrientationHelper.VERTICAL, false); rv.setLayoutManager(mLayoutManager); //谷歌提供了一个默认的item删除增加的动画 rv.setItemAnimator(new DefaultItemAnimator()); rv.setHasFixedSize(true); //模仿列表数据 ArrayList newsList = new ArrayList<>(); TypedArray array = context.getResources().obtainTypedArray(context.getResources().getIdentifier("rc_emoji_res", "array", context.getPackageName())); int i = -1; while (++i < array.length()) { newsList.add(array.getResourceId(i, -1)); } rv.setAdapter(new NewsAdapter(newsList)); return view; } ...

March 16, 2021 · 1 min · jiezi

关于im:融云-IMkit-拦截或监听所有发送消息

最近集成融云 IMkit 的 SDK, 有一个需要是要监听所有收回去的音讯, 依据音讯类型拦挡或者进行批改. 在官网文档上着了一遍, 都没有找到, 偶尔在看 API 文档的时候看见了一个监听而后做了尝试, 是能够满足需要的, 所以再次记录一下. 具体的办法是 RongIM 类下的 setSendMessageListener 办法. 代码如下. /** 设置发送音讯的监听。* @param listener 发送音讯的监听。*/ RongIM.setSendMessageListener(new OnSendMessageListener() { @Override public Message onSend(Message message) { // 发送音讯之前会走此办法. message 为要发送的音讯, // 如果返回 null 的话, 就不会发送此音讯了. return message; } @Override public boolean onSent(Message message, SentMessageErrorCode sentMessageErrorCode) { 发送胜利之后会走办法. 返回 true , 就会走 SDK 的后续逻辑. 返回 false 就拦挡了. return true; } }).

March 16, 2021 · 1 min · jiezi

关于im:跳转到消息的位置

跳转到@音讯的地位 1./** 获取某会话里未读的@音讯。 *@param conversationType 会话类型。@param targetId 指标 Id。依据不同的 conversationType,可能是用户 Id、讨论组 Id、群组 Id。@param callback 获取未读@音讯的回调。回调里返回的音讯列表,依照工夫程序从旧到新。最多返回最近的十条未读 @ 音讯。*/ public void getUnreadMentionedMessages(final Conversation.ConversationType conversationType, final String targetId, final ResultCallback<List<Message>> callback)2./** <p>启动会话界面,并跳转到指定的音讯地位</p><p>应用时,能够传入多种会话类型 {@link io.rong.imlib.model.Conversation.ConversationType} 对应不同的会话类型,开启不同的会话界面。如果传入的是 {@link io.rong.imlib.model.Conversation.ConversationType#CHATROOM},sdk 会默认调用{@link RongIMClient#joinChatRoom(String, int, RongIMClient.OperationCallback)} 退出聊天室。如果你的逻辑是,只容许退出已存在的聊天室,请应用接口 {@link #startChatRoomChat(Context, String, boolean)} 并且第三个参数为 true</p>* @param context         利用上下文。@param conversationType 会话类型。@param targetId         依据不同的 conversationType,可能是用户 Id、讨论组 Id、群组 Id 或聊天室 Id。@param title           聊天的题目。开发者须要在聊天界面通过intent.getData().getQueryParameter("title")获取该值, 再手动设置为聊天界面的题目。@param fixedMsgSentTime 须要定位的音讯发送工夫*/ public void startConversation ...

March 15, 2021 · 1 min · jiezi

关于im:融云IMKit-动态删除或添加plugin-的实现

在集成融云的过程中,因为我的项目要求比拟紧急,所以应用了融云的IMKit (带有UI界面的),然而因为应用融云方面的自带的UI ,所以就会不可避免的就会有些自定义化的需要; 接下来,我就我的项目中应用到的 动静删除或增加plugin 的计划给大家介绍一下。ps:满满的私货,官网文档并没有动静的形式。 第一步:须要先复写 ConversationFragment ,在onCreateView 办法中找到 RongExtension 控件 。 public class ConversationFragmentEx extends ConversationFragment { private RongExtension rongExtension; @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { View v = super.onCreateView(inflater, container, savedInstanceState); rongExtension = (RongExtension) v.findViewById(io.rong.imkit.R.id.rc_extension); return v; }} 第二步:再复写 initFragment 办法获取 targetId。(按需进行获取,若是不须要则无需获取) @Override protected void initFragment(Uri uri) { super.initFragment(uri); if (uri != null) { String TargetId = uri.getQueryParameter("targetId"); } } 第三步:而后再onResume办法中依据 targetId进行删除或减少(我的项目需要) @Override public void onResume() { super.onResume(); List<IPluginModule>  PluginModules = rongExtension.getPluginModules(); for(int i=0;i<PluginModules.size();i++){ if(PluginModules.get(i) instanceof DefaultLocationPlugin){ rongExtension.removePlugin(PluginModules.get(i)); } } } ...

March 12, 2021 · 1 min · jiezi

关于im:融云自定义消息不显示

我的项目用的融云,IMKit SDK(自带 UI),然而呈现一个问题,就是自定义音讯在会话页面刚收到的时候能显示,然而退出会话页面再进入就不显示了。十分的纳闷啊。查问了存储策略,编解码办法,都没有问题。起初提交工单,技术人员给了反馈才发现自己把音讯的注册放到了初始化 appkey 前边,而后人家融云写的很明确:应用融云SDK所有性能(包含显示SDK中或者继承于SDK的View)之前,您必须先调用此办法初始化 SDK。可见认真查看文档接口正文的重要性!! /*! 初始化融云SDK @param appKey 从融云开发者平台创立利用后获取到的App Key @discussion 您在应用融云SDK所有性能(包含显示SDK中或者继承于SDK的View)之前,您必须先调用此办法初始化SDK。 在App整个生命周期中,您只须要执行一次初始化。 @warning 如果您应用IMKit,请应用此办法初始化SDK; 如果您应用IMLib,请应用RCIMClient中的同名办法初始化,而不要应用此办法。 */- (void)initWithAppKey:(NSString *)appKey;

November 18, 2020 · 1 min · jiezi

关于im:如何利用融云-IMLib-来实现一个阅后即焚功能

场景我的项目须要在私聊中来实现一个阅后即焚的性能,即 A 用户给 B 用户发送音讯,B 用户在进入聊天页面查看之后 A 用户删除此音讯,B 用户开始进入倒计时,倒计时完结后,删除此音讯。 思考大体的梳理一下具体的逻辑 A -> BB 进入会话页面B 将此音讯开始倒计时告诉 A 我已进行浏览A 删除音讯从下面内容咱们来大体的设计一下咱们须要用户的技术 单例类自定义音讯,用来通知 A 我曾经开始浏览了,你删除吧一个用于保护阅后即焚音讯的治理类一个存储 A 给 B 发送的所有的阅后即焚的音讯的容器 A <k, v> k 为 targetid ,v 为 messageIDs一个存储每条阅后即焚音讯的容器 B <k,v> k 为 messageId, v 为以后音讯还剩的倒计时工夫。一个用来存储所有阅后即焚音讯的容器 C K:ID V:msg两个解决队列 一个解决工夫 一个解决音讯对外裸露接口 代理 接管方焚烧音讯的每秒倒计时告诉 接管方收到对方已浏览某条音讯的告诉详解初始化咱们的所有容器收到音讯,在适合的业务机会将此音讯退出到焚烧队列查问音讯是否曾经在焚烧队列如果不在,增加到 A B C容器执行倒计时倒计时操作 遍历 C 是否有音讯给发送方发送音讯,告诉我曾经开始焚烧 A 里的音讯了 并在 A 容器删除此会话发送方收到音讯发送告诉接管方遍历 B 容器,判断每条音讯是否到时如果音讯焚烧工夫到 在 A、B 容器删除,并触发代理如果没到工夫,就触发代理并批改 此音讯在 B 容器的时长。

November 18, 2020 · 1 min · jiezi

关于im:融云-IMKit-音频录制参数

场景: 应用融云自带的界面进行语音音讯的播放。本人进行音频录制。应用的融云的 RCHQMessage问题: 语音音讯 iOS 和 Android 不互通,接管到音讯之后无奈播放。解决方案: 通过与融云开发者的确认,应用时必须保障如下录制参数: iOS AVAudioRecorder 录制参数如下设置: AVFormatIDKey : @(kAudioFormatMPEG4AAC_HE),AVSampleRateKey : @(44100.0),AVNumberOfChannelsKey : @1,AVEncoderBitRateKey : @(16000)Android MediaRecorder 录制参数如下: setAudioSamplingRate(44100);setAudioEncodingBitRate(16000);setAudioChannels(1);setAudioSource(MediaRecorder.AudioSource.MIC);setOutputFormat(MediaRecorder.OutputFormat.MPEG_4);setAudioEncoder(MediaRecorder.AudioEncoder.HE_AAC);其余一些内容的应用能够本人去官网文档搜寻: 融云文档:https://docs.rongcloud.cn/v4/

November 18, 2020 · 1 min · jiezi

关于im:给融云的输入框上方加个功能按钮怎么整

给输入框上方加个性能按钮,相似常用语或者抽奖啥的,是个挺广泛的需要,惋惜遍寻文档(https://docs.rongcloud.cn/v4/...,只能靠本人了,咱们来看看怎么做吧。 首先,咱们要先在聊天页面增加个属性,也就是须要性能按钮所在的 view @property (nonatomic, strong) UIView *needAddView;再就是须要重写 viewWillAppear 生命周期函数,增加这个 needAddView,设置 UI 布局,保障进入页面时,needAddView 能够正确显示 - (void)viewWillAppear:(BOOL)animated { [super viewWillAppear:animated]; //初始化 needAddView,增加到 self.view 上,坐标 y = 输入框的 y 坐标 - needAddView 高度 CGFloat needAddView_height = 50.f; CGFloat y = self.chatSessionInputBarControl.frame.origin.y - needAddView_height; self.needAddView = [[UIView alloc] initWithFrame:CGRectMake(0, y, self.conversationMessageCollectionView.frame.size.width, needAddView_height)]; self.needAddView.backgroundColor = [UIColor blueColor]; [self.view addSubview:self.needAddView]; //设置音讯内容 collectionView 的高度,要减去 needAddView 的高度,防止被遮挡。 CGRect frame = self.conversationMessageCollectionView.frame; frame.size.height -= needAddView_height; self.conversationMessageCollectionView.frame = frame;}最初须要依据输入框的地位变动,对 UI 布局做扭转 ...

November 6, 2020 · 1 min · jiezi

关于im:如何隐藏融云输入框语音按钮

我的项目中应用了融云自带页面的 IMKit SDK,产品需要是不须要输入框处的语音按钮。发现 SDK 接口还是比拟弱小的,然而须要认真的查看 .h 文件 API 正文。间接应用聊天页面的 chatSessionInputBarControl 属性即可.它外部有接口能够设置输入框类型: 上代码: - (void)viewDidLoad { [super viewDidLoad]; [self.chatSessionInputBarControl setInputBarType:RCChatSessionInputBarControlDefaultType style:RC_CHAT_INPUT_BAR_STYLE_CONTAINER_EXTENTION];}

November 6, 2020 · 1 min · jiezi

关于im:使用融云-IM-点击最近聊天记录时跳转到-自己的消息

有没有遇到过这样的问题,在最近聊天记录列表外面有 @ 你的音讯,点列表外面对应的记录,进入聊天页面当前,跳到了最新接管到的音讯,想要看 @ 本人的音讯,还得可劲儿的下来去找,应用体验不好,想要改善的话,往下看。 实现思路就是获取会话中 @ 本人的音讯,把这条音讯的工夫传给聊天页面,而后再跳转,就能够跳转到这条音讯了。 在 push 到会话页面之前,调 RCIMClient 类上面接口,获取 @ 本人的音讯/*! 获取会话中@揭示本人的音讯 @param conversationType 会话类型 @param targetId 指标会话ID @discussion 此办法从本地获取被@揭示的音讯(最多返回10条信息) @warning 应用 IMKit 留神在进入会话页背后调用,否则在进入会话革除未读数的接口 clearMessagesUnreadStatus: targetId: 以及 设置音讯接管状态接口 setMessageReceivedStatus:receivedStatus:会同步革除被提示信息状态。 */- (NSArray *)getUnreadMentionedMessages:(RCConversationType)conversationType targetId:(NSString *)targetId;遍历失去数组,找到本人想要跳转到的音讯,把音讯的 sentTime 传给要跳转的聊天页面,再 push 到聊天页面。/** 进入页面时定位的音讯的发送工夫 @discussion 用于音讯搜寻之后点击进入页面等场景 */@property (nonatomic, assign) long long locatedMessageSentTime;示例代码 - (void)onSelectedTableRow:(RCConversationModelType)conversationModelType conversationModel:(RCConversationModel *)model atIndexPath:(NSIndexPath *)indexPath { if (model.conversationType == ConversationType_GROUP) { NSArray *msgs = [[RCIMClient sharedRCIMClient] getUnreadMentionedMessages:model.conversationType targetId:model.targetId]; if (msgs.count > 0) { RCMessage *msg = msgs[0]; RCConversationViewController *vc = [[RCConversationViewController alloc] initWithConversationType:model.conversationType targetId:model.targetId]; vc.locatedMessageSentTime = msg.sentTime; [self.navigationController pushViewController:vc animated:YES]; } }}代码接口文档:https://docs.rongcloud.cn/v4/... ...

November 6, 2020 · 1 min · jiezi