收录了 消息队列技术架构图 频道下的 50 篇内容
本文是架构设计实践五部曲系列文章的第五篇,技术架构的战略和战术原则。本篇讲述如何保证在做技术架构时,实现一个稳定、出色的系统。
时常会思考消息队列的价值是什么?新人加入团队后该如何理解消息队列?又该如何理解小米的自研产品 Talos 和 EMQ?
本文以一张云进化历史图开场,来谈谈云原生时代消息中间件的演进路线。
企业系统和网站系统都需要处理大量的邮件、短信等消息通知系统。在进行系统设计时,除了对安全、事务等问题给与足够的重视外,性能也是一个不可避免的问题所在,必须充分地考虑访问量、数据流量、服务器负荷的问题。解决性能的瓶颈,除了对硬件系统进行升级外,软件设计的合理性尤为重要。对于一些实时性不是很高的模块我们可以使用了消息队列技术来完成异步处理,利用消息队列临时存放要操作的数据,将队列的数据进行异步的处理。本文基于SQL Server 2008 Service Broker、WCF、Windows 服务以及调度框架Quartz.NET实现一个消息通知系统。
前言 IM全称是『Instant Messaging』,中文名是即时通讯。在这个高度信息化的移动互联网时代,生活中IM类产品已经成为必备品,比较有名的如钉钉、微信、QQ等以IM为核心功能的产品。当然目前微信已经成长为一个生态型产品,但其核心功能还是IM。
全面解读 RocketMQ 5.0 架构演进。
随着网络基础设施的逐步成熟,从RPC进化到Web Service,并在业界开始普遍推行SOA,再到后来的RESTful平台以及云计算中的PaaS与SaaS概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。正如Martin Fowler在《企业集成模式》一书的序中写道:“集成之所以重要是因为相互独立的应用是没有生命力的。我们需要一种技术能将在设计时并未考虑互操作的应用集成起来,打破它们之间的隔阂,获得比单个应用更多的效益”。这或许是分布式架构存在的主要意义。
本文从去哪儿网使用消息队列所碰到的各种问题出发探讨去哪儿网消息队列的设计与实现。
这篇文章主要探讨什么是技术架构、技术架构要解决的问题、最后以高并发场景为例画出技术架构图。
在日益复杂的业务背景下,任意延迟等级的队列也会被提上议程。
DTIM 需要能够面对复杂场景,保持良好的可用性和体验,同时兼顾性能与成本。
消息队列作为关键技术基础设施之一,也在云原生时代面临着挑战和机会。
本文介绍 RocketMQ 4.6.0 版本的新特性Request-Reply。
IM消息作为闲鱼用户重要的交易咨询工具,核心目标有两点,第一是保证用户的消息不丢失,第二是保证用户的消息及时送达接收方。
Apache Pulsar 是云原生的分布式消息流系统,采用了计算和存储分层的架构和以 Segment 为中心的分片存储,因此 Apache Pulsar 具有更好的性能、可扩展性和灵活性,是一款可以无限扩展的分布式消息队列。
这几天拜读了郭斯杰的《Messaging,Storage,or both?》一文,大有感触,作者分享了自己过去几年时间里在工作中使用Apache Pulsar、DistributedLog,以及BookKeeper的实际经验。本文我将会解读他的这篇文章,并且加入我自己的实际理解和使用经验。
本文主要剖析了分布式队列编程模型的需求来源、定义、结构以及其变化多样性;根据作者在新美大实际工作经验,给出了队列式编程在分布式环境下的一些具体应用。
面对诸多的分布式消息中间件,金融企业面临如何选择并确定适合企业长期发展的相应开源软件。金融行业开源软件研究工作组结合金融企业的实际应用场景,针对主流的开源分布式消息中间件建立评测并开展评测实施,以支撑金融企业选择成熟度高、适合企业需求的开源软件。
消息推送作为移动 APP 运营中的一项关键技术,已经被越来越广泛的运用。本文追溯了推送技术的发展历史,剖析了其核心原理,并对推送服务的关键技术进行深入剖析,围绕消息推送时产生的服务不稳定性,消息丢失、延迟,接入复杂性,统计缺失等问题,提供了一整套平台级的高可用消息推送解决方案。实践中,借助于该平台,不仅能提能显著提高消息到达率,还能提高研发效率,并道出了移动开发基础设施的平台化架构思路。