- 综合排序
- 最热优先
- 最新优先
- 来自专栏音视频咖
新知 | 低延时、高可靠、高稳定、高安全的即时通信IM技术
今天的新知系列课，我们邀请到了来自腾讯云即时通信IM团队的技术导师 —— 陈锐龙，为大家介绍腾讯云即时通信IM是如何构建低延时高可靠高稳定以及高安全方面的通信能力，以及底层的核心技术支撑跟技术特性。 ，为客户构建稳定安全的消息通道。 确定协议后，我们从Chromium项目，剥离出Quic源码，定制封装成四层支持全双工通信的Quic协议库，并应用在通信网的节点传输上，作为加速网络高可靠传输的保障。 高安全性也是通信网的核心特性之一，我们在端侧采用了QQ同款的加密级别，同时数据加速节点后，又加了一层Quic自身加密算法，双重加密，确保数据在公网传输时更难被检测跟解密，数据传输更安全更有保障。 、高可靠以及高安全的底层通信能力，为APP提供快速可靠的访问体验。
2.8K20编辑于 2021-12-06 - 来自专栏InvQ的专栏
RocketMQ消息高可靠详解
master和slave都可以提供读服务，但是只有master允许做写入操作，slave仅从master同步数据并不断上报自己的同步进度（slave自己的物理max offset）。
43240编辑于 2023-04-04 - 来自专栏腾讯开源的专栏
【开源公告】“高可用、高吞吐、高可靠”分布式队列PhxQueue开源
PhxQueue PhxQueue 是微信开源的一款基于 Paxos 协议实现的高可用、高吞吐和高可靠的分布式队列，保证At-Least-Once Delivery，目前在微信内部广泛支持微信支付、 其设计出发点是高数据可靠性，且不失高可用和高吞吐，同时支持多种常见队列特性： * 同步刷盘，入队数据绝对不丢，自带内部实时对账 * 出入队严格有序 * 多订阅 * 出队限速 * 出队重放 * 所有模块均可平行扩展 * 存储层批量刷盘、同步，保证高吞吐 * 存储层支持同城多中心部署 * 存储层自动容灾/接入均衡 * 消费者自动容灾/负载均衡 高可用、高可靠、高性能的分布式队列PhxQueue正式开源 Github
1.1K61发布于 2018-03-02 - 来自专栏桥路_大数据
Kafka如何保证数据高可靠
当这种ack可以设为-1的时候，数据安全性是最高的。0安全级别最低，1安全级别中等。 没有足够的副本，保证不了数据安全。 所以一般来说它俩是配合来使用的，避免ack=all降级为ack=1，能够提升我们数据安全级别。 所以我们也印证了前面说的，为什么Kafka它不是一个金融级别可用的，或者金融级别数据安全的消息系统。原因就在这里。 这个时候有的同学就很矛盾了，我既想用Kafka的这种高性能高吞吐，但是我又不希望它丢数，我们换一种思路该怎么办？ 依赖kafka的高性能同时，尽量减少对kafka数据可靠性的依赖，并协调生产者与消费者去保障数据问题，这种解决方案能够满足生产上多数需求。 那Kafka的数据可靠性，就聊到这里，谢谢大家。
38720编辑于 2023-10-16 - 来自专栏加米谷大数据
Flume的高可靠，高性能和高扩展性
官网：https://flume.apache.org/ Flume 是Apache旗下的一款开源、高可靠、高扩展、容易管理、支持客户扩展的数据采集系统。 使用内存性能高但不持久，有可能丢数据。使用文件更可靠，但性能不如内存。 Sink Sink负责从管道中读出数据并发给下一个Agent或者最终的目的地。
89020发布于 2018-07-25 - 来自专栏架构师之路
高并发、高可用、高可靠微服务架构7大顶级设计思维模型
《百万年薪架构师必备能力—亿级企业高可用高并发高可靠微服务架构设计与实践》。
1.2K30发布于 2021-04-22 - 来自专栏程序猿的大杂烩
搭建高可用高可靠的RabbitMQ镜像队列集群架构
100%数据可靠性解决方案一般是3节点以上） 在本文中将要搭建的RabbitMQ集群架构如下： ? ---- RabbitMQ集群整合负载均衡基础组件HAProxy 在上一小节中，我们搭建了RabbitMQ的镜像队列集群，虽然集群节点之间能够同步数据保证高可靠的存储了，但有个问题就是客户端通常只能连接集群中的其中一个节点 HAProxy是一款提供高可用性、负载均衡以及基于TCP（第四层）和HTTP（第七层）应用的代理软件，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。 并且它的运行模式使得它可以很简单安全的整合进你当前的架构中，同时可以保护你的web服务器不被暴露到网络上。 因此，我们需要结合KeepAlived组件实现两个HAProxy节点的主备切换，达到高可用的目的。 KeepAlived软件主要是通过VRRP协议实现高可用功能的。
1.9K10发布于 2020-12-01 - 来自专栏一个执拗的后端搬砖工
高并发场景缓存真的可靠吗？
高并发场景缓存真的可靠吗？ ? 缓存提供的核心的能力是查询高性能与承受高qps，一般是纯内存(jvm缓存)或类内存(redis)操作，缓存 使用流程大概如图： ? 并且查询频率远大于更新频率，对于缓存的使用，大多数中小型应用使用以上图中所描述的链路基本不会存在什么问题，但是我们要思考一个问题，在并发很大的场景下，单纯的使用缓存来抵抗高qps真的可靠吗？ 在此处输入标题 在互联网大环境中，很多复杂的场景并不能单纯的依靠一种手段来做到尽善尽美，有时候几种技术实现融合到一起能够更好地解决问题，对于本篇所讲述的高并发场景下，单纯的依靠缓存来解决高QPS 问题其实是不可靠的，因为缓存实现层也不是无限的资源，这种情况下就需要根据应用服务器的承受能力，数据库层的处理能力以及缓存层的QPS流量限制，来对应用的处理能力做一个合理的评估，然后对超过处理能力的部分流量丢弃或者说削峰处理
1.4K30发布于 2020-11-19 - 来自专栏一英里广度一英寸深度的学习
Kafka-0.10.0.0 集群高可靠实验
bin/zkServer.sh start zookeeper状态和高可靠 bin/zkServer.sh status 命令输出 ZooKeeper JMX enabled by default 至此，完成zookeeper的安装、集群配置以及集群可靠性验证。 二、Kafka安装 解压kafka-0.10.0.0到/opt/kafka路径中，3个主机组成Kafka集群。 三、Kafka可靠性验证 1.关闭broker0 bin/kafka-server-stop.sh 2.查看topic信息 Topic:exam2 PartitionCount:10 ReplicationFactor 通过手动关闭进程的方式，实现了kafka高可用性、负载均衡。
90020发布于 2018-09-12 - 来自专栏腾讯技术工程官方号的专栏
Kafka 高可靠高性能原理探究
通过上述例子可以发现交易、支付等场景常需要异步解耦和削峰填谷功能解决问题，而交易、支付等场景对性能、可靠性要求特别高。那么，我们本文的主角 Kafka 能否满足相应要求呢？下面我们来探讨下。 Kafka 高可靠性、高性能探究 在对 Kafka 的整体系统框架及相关概念简单了解后，下面我们来进一步深入探讨下高可靠性、高性能实现原理。 Kafka 高可靠性探究 Kafka 高可靠性的核心是保证消息在传递过程中不丢失，涉及如下核心环节： 消息从生产者可靠地发送至 Broker；-- 网络、本地丢数据； 发送到 Broker 的消息可靠持久化 注意：所有副本都有对应的 HW 和 LEO，只不过 Leader 副本比较特殊，Kafka 使用 Leader 副本的高水位来定义所在分区的高水位。 换句话说，分区的高水位就是其 Leader 副本的高水位。
1.8K43编辑于 2023-05-08 - 来自专栏about云
flume与kafka整合高可靠教程
kafka安装 flume与kafka整合很多人都用到，但是网上却没有一份详细可靠的教程。说的都是些只言片语。这里整理份flume与kafka整合的教程。 flume原先并不兼容kafka。
2.3K90发布于 2018-03-26 - 来自专栏EAWorld
应用高可靠助力企业运维
在高并发场景下（如商品秒杀，抢票等），大量的请求会涌入web服务器中。如何防止业务无法按用户预期提供正常服务的问题，提高用户的使用体验，是所有服务器中间件都要面临的挑战。 提供应用在线率，出现问题快速解决，是提高用户体验的重要手段，应用高可靠性已经具有十分重要的意义。 应用高可靠有三大难点： 难点一：应用出现类冲突如何解决 比如，应用错误的引入了一个三方jar包的多个版本，或应用中不同的三方jar之中存在相同全限定名的类，这种存在的类冲突该如何解决。 本文将以运维的角度介绍如何解决普元应用服务器（PAS）在应用部署，运行时遇到类冲突问题，应用运行时出现问题如何定位，来保证应用运行时的高可靠性。 针对该场景，通过PAS的长线程检测功能，及时发现耗时异常的业务，即时查找问题保证应用高可靠性。
1.3K50编辑于 2022-09-27 - 来自专栏Java探索之路
Flume——高可用的、高可靠的、分布式日志收集系统
，高可靠的，分布式的海量日志采集、聚合和传输的系统， Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。 这样配置可能会导致单点故障 , 因此可以配置高可用 流复用模式 Flume支持将事件流复用到一个或多个目的地。 与Exec源不同，此源是可靠的，即使Flume重新启动或终止，它也不会丢失数据。为了获得这种可靠性，必须仅将不可变的唯一命名的文件放入Spooling目录中。 多个Source可以安全的写入到同一Channel中，并且多个Sink可以从同一个Channel中读取数据。 一旦在下一阶段或者其目的地中数据是安全的,Sink通过事务提交通知Channel，可以从Channel中删除这一事件。
1.9K30发布于 2020-07-24 - 来自专栏音视频技术
端侧AI：高隐私、高可靠的智能个性化服务
相较于云端AI需要用户将数据发送到云端进行处理，存在网络稳定性、隐私安全等问题。 随着终端算力的提升，端侧AI本地处理数据的高隐私性以及对用户使用习惯的智能感知，将为用户带来更可靠的个性化优质服务。 AI芯片除了要满足DSP对视频编解码的需求外，必定还需要支撑视频后处理的功能，因此对端侧的视频AI高算力需求是存在的。 所以可以同时克服高算力及低功耗两个截然不同方向的芯片能力，应该才能真正适应这变化万千的智能终端需求。 当前我们在设计端侧AI平台，我们希望从简单直接的安全加密保护逐渐迁移到芯片等级的安全通路设计，同时采取用后即焚的数据处理策略，避免数据缓存被拦截窃取及篡改等。
1.7K50发布于 2020-05-13 - 来自专栏腾讯技术工程官方号的专栏
基于Flink的高可靠实时ETL系统
GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是长期关注互联网技术与架构的高可用架构技术社区和msup推出的，面向架构师、技术负责人及高端技术从业人员的年度技术架构大会 今年的第六届GIAC大会上，在大数据架构专题，腾讯数据平台部实时计算负责人施晓罡发表了《基于Flink的高可靠实时ETL系统》的主题演讲。以下为嘉宾演讲实录： ? 而在2017年，腾讯大数据基于Flink在易用性、可靠性和性能上的优势，通过Flink对TDBank的数据接入进行了重构。相比于Storm，Flink对state提供了更多的支持。 所有节点在执行checkpoint时执行了预提交的操作，将所有数据都先写入到一个可靠的分布式存储中。当checkpoint在JobManager上完成时，即认为这个事务被提交了。 由于一般的指标系统并不能保证指标的时效性和正确性，因此我们也基于Flink实现了高可靠和强一致性的指标聚合。 ? 类似于数据链路，我们也采用Flink的checkpoint机制来保证指标数据的一致性。
1.8K50发布于 2020-09-01 - 来自专栏OpenIM
微信开源PhxQueue：高可用、高可靠、高性能的分布式队列
新需求 随着业务发展，接入业务种类日益增多，旧队列逐渐显得力不从心，主要不足如下： 异步刷盘，数据可靠性堪忧 对于支付相关业务，保证数据可靠是首要需求。 目前大多数分布式队列方案是以同步复制 + 异步刷盘来保证数据可靠性的，但我们认为需要同步刷盘来进一步提高数据可靠性。 其高吞吐、自动容灾、出入队有序等特性，吸引了众多公司使用，在数据采集、传输场景中发挥着重要作用，详见 Powerd By Kafka。 其设计出发点是高数据可靠性，且不失高可用和高吞吐，同时支持多种常见队列特性。 为了提高数据可靠性，同步刷盘作为默认开启特性，且性能不亚于异步刷盘。
90650发布于 2021-09-09 - 来自专栏运维开发王义杰
理解CAP定理：构筑高可靠系统的基石
了解并应用CAP定理，对于系统运维人员和架构师来说，是提高系统可靠性和性能的关键。 CAP定理的由来 CAP定理由加州大学伯克利分校的计算机科学家Eric Brewer在2000年提出。 这种权衡选择对于系统的性能和可靠性具有直接的影响。 提高系统可靠性：通过理解CAP定理，我们能够更好地设计和选择合适的技术和策略来提高系统的可靠性。 提高沟通效率：掌握CAP定理能够帮助系统运维人员和架构师更有效地沟通和协作，共同为提高系统的可靠性和性能做出贡献。 总结 CAP定理是每一个希望建设高可靠、高性能分布式系统的系统运维人员和架构师必须掌握的基础理论。
45420编辑于 2023-11-07 - 来自专栏深度学习与python
Netflix 如何打造高可靠在线有状态系统
构建可靠的有状态服务 构建可靠的大规模有状态服务需要结合以下三种技术： 构建可靠的有状态服务器 将它们与可靠的有状态客户端配对 改变有状态 API 的设计，以使用所有这些可靠性技术 可靠的有状态服务器 这种复制技术使我们能够进行高度可靠的写入和读取操作，因为我们可以使用仲裁来接受任何区域中的写入。由于在每个区域都有三个副本，我们可以提供非常高的可靠性，同时保持强一致性。 相对于服务而言，缓存成本较低；运行实际业务逻辑的无状态应用程序的运行成本相当高。这种技术可以帮助我们通过减少服务和数据存储必须处理的负载量来提高可靠性。 唯一的问题是高延迟影响。我们在 10 秒内从 40% 的利用率上升到 80%，因此延迟降级了。最后，我们的服务器自动扩展系统通过注入容量来恢复延迟 SLO，以弥补延迟影响。 可靠的有状态 API API 也必须支持上文介绍的所有这些技术。如果请求有副作用，你就无法重试请求！ 幂等性令牌 假设你必须重试；如何确保可变 API 的安全？答案是幂等性令牌。
39010编辑于 2024-06-17 - 来自专栏后台技术汇
《基于实践，设计一个百万级别的高可用 & 高可靠的 IM 消息系统》
下面我将从开发者的视角出发，一步一步的与大家一起剖析：如何去设计一个能支撑起百万级别的高可用高可用的 IM 消息系统架构； 下面我主要围绕着七个主题进行说明：项目背景、背景需求、实现原理、开发方案、对比方案 系统需求 我们将 IM 系统的需求需要满足四点：高可靠性、高可用性、实时性和有序性。 安全性 传输安全性使用 https 访问；使用私有协议，不容易解析； 内容安全性端到端加密，中间任何环节都不能解密；即发送和接收端交换互相的密钥来解密，服务器端解密不了；服务器端不存储消息； 2. 可靠性 上述方案用到了 ack 机制，同时消息创建过程尽量确保操作原子性，并且封装为一个事务（虽然分开 mysql&redis 存储让分布式事务变得较高难度）。 4. 云千万级并发消息处理能力的架构设计与实践》 《从新手到专家：如何设计一套亿级消息量的分布式IM系统》 《一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分》 《一套亿级用户的IM架构技术干货(下篇)：可靠性
2.6K42编辑于 2022-05-28 - 来自专栏架构之美
如何打造高可靠高性能的消息队列（ZZMQ）
MQ是以消息为载体的可靠异步调用的框架，能很好的应对上面三个问题。流量削峰，MQ是天然支持的，因为MQ有可靠存储，可以落地。解耦合，交给MQ也很合适。 MQ很好很强大，是RPC的有效补充，那问题来了怎么实现一个可靠MQ？本文结合二手交易平台的特点，详细介绍转转ZZMQ架构设计实践。 而我们的场景的是：业务大部分topic的qps并不像kafka处理的日志文件那么高，希望能单机支撑更多的topic数量。 高可用 Broker组由主从两台机器构成，可以配置的策略有同步双写和异步复制。默认情况，采用的异步复制，由slave去拉取master上面的消息Log和offset。 总结 本文主要介绍了转转ZZMQ在架构、存储系统、保证消息可靠存储，可靠消费，以及netty的使用等经验，分享出来，与大家一起探讨，欢迎拍砖指正。
2.1K40发布于 2018-07-03
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号