当前位置:首页 > 问答 > 正文

Redis的出现让网络结构变得不一样了,拓扑关系也被重新定义和影响着

主要基于对过去十多年间网络应用开发实践的观察,以及像CSDN、InfoQ等技术社区中众多开发者分享的经验总结,并结合了像《Redis实战》等书籍中提到的基本思想。)

Redis的出现,确实像一阵旋风,改变了许多人构建网络应用的方式,也让网络中的各个部分之间的关系,也就是拓扑关系,发生了深刻的变化,在Redis诞生之前,网络应用的架构相对而言是线性的、清晰的,但有时也显得笨重。

Redis的出现让网络结构变得不一样了,拓扑关系也被重新定义和影响着

回想一下早期的Web应用,典型的架构可能是这样的:用户通过浏览器发出请求,请求到达一个Web服务器(比如Apache或Nginx),这个服务器后面连接着一个应用服务器(比如用Java的Tomcat或用Python的Django/Flask框架写的服务),应用服务器为了记住用户的状态(比如是否登录、购物车里有啥),要么在服务器自身的内存里存一份(但这会导致服务器重启数据就没了,而且多台服务器之间难以同步),要么就是频繁地去访问后端的核心——关系型数据库,比如MySQL或PostgreSQL,所有的核心数据,用户信息、订单、文章内容,都稳稳当当地存放在这个数据库里,这是一种经典的“三层架构”:展示层、逻辑层、数据层,数据层是绝对的中心,是唯一的“真相来源”,拓扑关系像一棵树,数据库是树根,应用服务器是枝干,而用户请求是树叶,这种结构的优点是清晰,但瓶颈也明显:数据库成了最大的压力点,频繁的读写,尤其是那些复杂的查询,很容易让数据库不堪重负,影响整个系统的速度。

Redis的出现,就像是在这个稳固的三角形架构中,投入了一颗石子,激起了层层涟漪,重新绘制了网络结构的版图,它不是一个要取代传统数据库的“篡位者”,而是作为一个全新的角色——“内存数据结构存储”——加入了战场,它的速度极快,因为数据主要放在内存里,这让它能够处理远超传统数据库的读写请求量。

Redis的出现让网络结构变得不一样了,拓扑关系也被重新定义和影响着

这种速度优势,首先带来的改变是“缓存”角色的革命,过去,应用服务器也会尝试在本地做缓存,但如前面所说,局限性很大,Redis的出现,使得应用可以有一个独立于所有应用服务器的、共享的、高速的缓存层,拓扑关系不再是应用服务器直接、频繁地访问遥远的数据库了,应用服务器在需要数据时,会先“问一问”身边的Redis:“嘿,你有这个数据吗?”如果Redis有(缓存命中),就直接返回,省去了长途跋涉去数据库查询的漫长过程,这就像是在一个繁忙的城市里,在每个社区都设立了24小时便利店(Redis),居民(应用服务器)大部分日常需求在楼下就能满足,只有买非常特殊的东西才需要去市中心的大超市(数据库),这样一来,网络流量被重新分配了,去往数据库的流量大幅减少,数据库的压力骤降,整个系统的响应速度得到了质的提升,拓扑关系从“应用服务器 -> 数据库”的简单两点一线,变成了“应用服务器 -> Redis ->(必要时)数据库”的更为智能的两级跳。

更进一步,Redis的影响力远不止于充当一个简单的缓存,它丰富的数据类型(如字符串、列表、集合、哈希等)和原子操作,让开发者开始思考:有些原本必须由数据库承担的工作,是不是可以卸载到Redis上来?网络的拓扑关系被更深入地影响着。

Redis的出现让网络结构变得不一样了,拓扑关系也被重新定义和影响着

会话(Session)管理,过去,要实现多台应用服务器共享用户登录状态是个麻烦事,可以把用户的Session信息直接存储在Redis中,任何一台应用服务器收到请求,都能快速从中央Redis获取到用户状态,这时,Redis不再仅仅是缓存,它成了共享状态的枢纽,应用服务器本身变得“无状态”了,它们可以随时增加或减少,而不用担心数据不一致的问题,系统的弹性变得更好,拓扑关系从“有状态的应用服务器围绕数据库”变成了“无状态的应用服务器集群围绕着一个高速的状态与数据服务(Redis)”。

再比如,排行榜、消息队列、实时计数等功能,在过去,实现一个实时更新的排行榜可能需要数据库频繁地执行复杂的排序和更新操作,对数据库是巨大的考验,而Redis原生支持有序集合(Sorted Set),可以极其高效地处理这类需求,开发者会自然而然地设计成:应用服务器在处理完核心逻辑后,将排行榜相关的更新操作发送给Redis,而查询请求则直接由Redis服务,这样一来,这部分业务逻辑产生的数据流就不再经过核心数据库了,而是在应用服务器和Redis之间形成了一个新的、高效的“数据环”,数据库得以更加专注于需要强一致性和持久化的核心业务数据,网络拓扑中,出现了更多专门化的、围绕特定功能的“小循环”,而不是所有数据流都涌向同一个中心。

甚至,利用Redis的发布订阅(Pub/Sub)功能,可以轻松构建实时通信系统,如在线聊天室、实时通知等,不同的服务可以通过Redis来发布消息和订阅消息,进行解耦,这使得系统架构向事件驱动演进,服务之间的关系不再是严格的上下游调用,而是通过Redis这个“消息广播站”进行松散的、异步的通信,拓扑关系变得更加网状化、动态化。

Redis的出现,打破了传统网络架构中以关系型数据库为单一核心的“中心辐射”模型,它引入了一个新的、高速的、多功能的节点,这个节点承担了缓存、共享存储、消息代理等多重角色,这使得网络拓扑从简单、集中、有时僵化的树状结构,演变成了一个更复杂、更分散、也更具有弹性和高性能的网状或分层结构,应用服务器、Redis、传统数据库之间形成了新的协作关系和数据流动路径,Redis就像是一个强大的交通枢纽,它没有取代终点站(数据库),但却极大地优化了交通流,开辟了新的高速通道,让整个网络系统的运行效率和可扩展性提升到了一个全新的水平。