服务读写分离(读服务,写服务),是否可行?

简介: 系统分层架构有一个迭代和演进的过程(详见《互联网分层架构设计》)

系统分层架构有一个迭代和演进的过程(详见《互联网分层架构设计》),早期,系统分层架构如下:

image.png

  • 上游是需要数据的业务调用方
  • 下游是存储数据的数据库

随着架构的演进,可能要抽取出服务层(详见《互联网架构为什么要做服务化?》):

image.png

  • 上游通过RPC调用服务获取数据
  • 中间服务层从数据库获取数据
  • 下游是存储数据的数据库

大家都知道,数据库可以读写分离,为了职责更清新,架构设计上,服务能否读写分离呢?

image.png

如上图,服务化读写分离之后:

  • 业务方通过RPC分别调用读服务和写服务
  • 服务层分为读服务与写服务
  • 底层是高可用的数据库集群

当然,也有可能读服务与写服务读写的是不同的数据库,如上图:

  • 写服务访问写库
  • 读服务访问读库
  • 写库与读库是一个主从同步的集群。

那么,问题来了:

  • 你遇到过这种架构设计么?
  • 这种架构设计好还是不好,为什么?
  • 如果服务读写分离设计好,上面两种方案哪种好?

欢迎讨论,将从评论中精选出三条有独特见解的留言,发放58元精美计算机图书兑换券。

也欢迎转发,大家一起讨论。

目录
相关文章
|
1月前
|
存储 缓存 数据库
解决缓存与数据库的数据一致性问题的终极指南
解决缓存与数据库的数据一致性问题的终极指南
150 63
|
2月前
|
存储 SQL 关系型数据库
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
MySQL如何进行分库分表、数据迁移?从相关概念、使用场景、拆分方式、分表字段选择、数据一致性校验等角度阐述MySQL数据库的分库分表方案。
400 15
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
|
1月前
|
SQL 存储 关系型数据库
关于主从延迟,一篇文章给你讲明白了!
关于主从延迟,一篇文章给你讲明白了!
|
2月前
|
消息中间件 缓存 NoSQL
15)如何保证缓存和数据库之间的数据一致性
15)如何保证缓存和数据库之间的数据一致性
59 1
|
4月前
|
canal 消息中间件 缓存
面试题:如何解决缓存和数据库的一致性问题?
面试题:如何解决缓存和数据库的一致性问题?
86 1
|
5月前
|
缓存 NoSQL Java
高并发场景下缓存+数据库双写不一致问题分析与解决方案设计
高并发场景下缓存+数据库双写不一致问题分析与解决方案设计
|
5月前
|
canal 缓存 关系型数据库
高并发场景下,6种方案,保证缓存和数据库的最终一致性!
在解决缓存一致性的过程中,有多种途径可以保证缓存的最终一致性,应该根据场景来设计合适的方案,读多写少的场景下,可以选择采用“Cache-Aside结合消费数据库日志做补偿”的方案,写多的场景下,可以选择采用“Write-Through结合分布式锁”的方案,写多的极端场景下,可以选择采用“Write-Behind”的方案。
1273 0
|
缓存 人工智能 关系型数据库
数据库主从延迟导致查询不准确的解决思路
实现固然重要,但更为重要的是思路;很多底层的原理与思想是通用的
480 5
|
消息中间件 canal 缓存
缓存数据一致性探究
缓存是一种较低成本提升系统性能的方式,自它面世第一天起就备受广大开发者的喜爱。然而正如《人月神话》中的那句经典的“没有银弹”中所说,软件工程的设计没有银弹。 就像每一次发布上线修复问题的同时,也极易引入新的问题,自缓存诞生的第一天起,缓存与数据库的数据一致性问题就深深困扰着开发者们。 关键词:原子性、事务性、数据一致性、双写一致性
6544 1
缓存数据一致性探究
|
SQL 关系型数据库 MySQL
这篇MySQL主从复制与分库分表读取分离稳了!
这篇MySQL主从复制与分库分表读取分离稳了!
151 0