前言
如果有幸目睹过系统从零到一的演变过程,大家估计都会有一种感叹,就是随着业务复杂度和流量的不断上升,系统变得越来越难以维护,面对高额的维护成本,攻城师们不得不对现有架构进行改造升级,以便使得系统更适合当下业务的发展。
说到架构改造升级,那到底该怎么改造呢?从哪里入手比较合适呢?这是一个比较大的话题,一两句话没办法讲述清楚,但是有一个出发点肯定是没有错的,就是为了更好的适应业务的发展需要进行必要的改造。
假设几个场景,场景一:用户 A 刷了微博,可能对某类博主比较感兴趣,为了让用户 A 看到更多可能感兴趣的人,该怎么做呢?场景二:用户 A 修改了年龄,搜索部门为了给其推荐可能感兴趣的商品,需要实时知道用户修改年龄的动作,采用何种方式来降低用户部门和搜索部门的耦合程度呢?场景三:京东 618 当天,大佬们想要看到实时成交总额,但又不能影响业务正常运行,又该怎么做呢?从以上几个例子可以看出,为了使得消息传递实时(说一下作者对实时的理解:在用户能接受的时间范围内得到想要的结果就是实时),降低业务部门的耦合度,需要有一个“中介”从中传递从而达到目的。
各消息队列对比
主流消息队列特性对比如下
特性 | Kafka< |
---|