论 业务系统 架构 的 简化 (二) 用 关系数据库 作 缓存

通常, 分布式缓存 是 NoSql 数据库, 比如 Redis  。

但 实际上 我们 可以用 关系数据库 来 作 缓存  。

比如 常用的 商品列表 等, 可以用 关系数据库 来作 缓存, 查询 排序 维护 都很方便 。

这种情况 其实 就是 在 主数据库 外 再建一个 数据库 用于 查询,

通过 Job 定时 同步 主数据库 的 资料 到 这个 “缓存”数据库 就可以 。

根据需要, 我们可以在 主数据库 外 建立 多个 “缓存”数据库, 也可以 称为 外围数据库, 周围数据库, 卫星数据库  。

通过 Job 定时 同步数据 到 这些 卫星数据库  。

这样的架构,  井然有序 。

在 大环境 上, 硬件技术 和 关系数据库技术 在 近几年 取得了 长足 的 进步,  并且这一趋势在未来还将延续 。

可以看看这篇文章   《CAP, BASE, 最终一致性和五分钟原则》    https://blog.csdn.net/u013613428/article/details/55259924

里面提到  “内存是硬盘,  硬盘是磁带”  。

分布式缓存 , 比如 Redis ,  可以作为 集群 的 共享内存,  Server 们 通过 Redis 来 共享数据, 通信, 同步协作 。

Redis 提供的一些数据类型还是 颇具价值 的,  比如 队列 Queue,  以及 Block Pop 等 Block 操作 。

可以用于 Server 间   共享数据, 通信, 同步协作  。

Server 间 的 共享数据, 通信, 同步协作   和   线程间 的   共享数据, 通信, 同步协作  是 类似的 ,

线程间 通过 内存 来 共享数据, 通过 Lock 来 同步协作,

Server 间 则 利用 Redis 这样的 分布式缓存 作为 共享内存, 利用 Redis 提供的 Lock ,  或者 Block 操作 来 同步协作 。

原文地址:https://www.cnblogs.com/KSongKing/p/9928412.html

时间: 2024-11-09 03:15:25

论 业务系统 架构 的 简化 (二) 用 关系数据库 作 缓存的相关文章

讲讲金融业务(二)--银行自助结算业务系统架构(A)

本篇论文主要读者适合对银行业务感兴趣的技术开发者,我这里尽量用普通读者能读懂的语言来描述银行自助结算业务系统架构. 在讲之前,先要阐述一个概念,即银联: 银联即各家银行的联合体,各家加入银联的银行都是银联的股东,银联的主要业务为:POS/ATM等自助结算收单业务,银联在线支付,互联网手机支付三项业务. 在没有银联的之前,自助结算业务系统架构是下面这样子的: 即自助结算终端将根据各家银行卡的交易转发至相应的银行.事实上各家银行部署的自助结算终端只受理本行业务.因此,自助结算终端的功能极其受限,比如

电商系统架构总结(二)

二  Redis缓存 考虑到将来服务器的升级扩展,使用redis代替.net内置缓存是比较理想的选择.redis是非常成熟好用的缓存系统,安装配置非常简单,直接上官网下载安装包 安装启动就行了. 1 配置.redis安装后默认bind 接口是127.0.0.1,也就是本地回环地址.在开发环境下为了允许多个开发机器作为客户端访问,bind配置后面加上了本机局域网ip,如  bind 127.0.0.1 192.168.1.100 . 2  配置了redis读写分离.开发web  api端的web.

Android系统架构剖析(二)之应用框架演变

Android系统体系结构中,整个Android体系被分为4层: 但是Android系统为什么要采取这样的分层方式呢?在这里我想介绍一下我们软件领域的应用框架发展情况. 在早期的时候,开发软件所使用的api都是直接调用系统的api.如果系统的api想要变化,那么势必会导致之前基于这个系统开发出来的所有软件应用都会付诸东流,代价高的很,所以在那个时候,操作系统的api都不会轻易的改变,软件执行的控制权全部掌握在开发者的手中,这也就限制了操作系统平台的发展,使得平台的弹性大大的降低.如图所示: 为了

业务系统技术架构的方法论

业务类系统(通常称为To B 类产品),一般包括crm,供应链,物流等.系统的架构设计非常具有挑战性. 面向用户的To C 类前台产品,无论产品经理还是用户都已经培养起了使用习惯,对功能有一定程度的理解,见过的模式足够多,能够建立起一定的产品模型,也容易找到参照物去模仿.但是业务类的系统,常常是没有参照和模仿,一些业务流程的不同,一点公司组织结构的不同,你家的CRM和他家的CRM可能完全没有参考性.所以在搭建产品架构的时候则要求产品经理非常懂业务,考验PM能力的同时,对技术架构也具备很大的挑战.

【58沈剑架构系列】秒杀系统架构优化思路

一.秒杀业务为什么难做 1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息): 2)微博系统,每个人读你关注的人的数据,一个人读多个人的数据: 3)秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据,多个人读一个数据. 例如:小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如:12306抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存.读写冲突,锁非常严重,这是秒杀业务难的地方.那我们怎么优化秒杀业务的架构呢? 二

秒杀系统架构优化思路

[总结] 上文应该描述的非常清楚了,没什么总结了,对于秒杀系统,再次重复下我个人经验的两个架构优化思路: (1)尽量将请求拦截在系统上游(越上游越好): (2)读多写少的常用多使用缓存(缓存抗读压力): 浏览器和APP:做限速 站点层:按照uid做限速,做页面缓存 服务层:按照业务做写请求队列控制流量,做数据缓存 数据层:闲庭信步 并且:结合业务做优化 一.秒杀业务为什么难做 1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息): 2)微博系统,每个人读你关注的人的

TOP100summit:【分享实录-美团点评】 业务快速升级发展背后的系统架构演进

本篇文章内容来自2016年TOP100summit美团●大众点评高级技术专家,酒店后台研发组eHome团队负责人许关飞的案例分享.编辑:Cynthia 许关飞:美团●大众点评高级技术专家,酒店后台研发组eHome团队负责人.新美大高级技术专家. 2012年加入美团,主导了新美大酒店业务从通用团购模式到专业酒店预订的技术转型:负责过美团酒店预订业务系统,平台系统,目前带领酒店孵化业务技术团队. 导读: 新美大以团购作为切入点,为了更好的连接用户与商户,从2012年开始在酒店.外卖.电影等垂直领域深

系统架构师-基础到企业应用架构-业务逻辑层

一.上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具 体实现方式简单的分为面向过程与面向对象的开发方式,而目前更多的是面向对象的开发设计方式.并且我们也讲述了该如何通过设计手段去分析功能点及设计分离 点,应该如何在设计的过程中分析的角度及如何去满足设计规范与原则.首先我们通过下图来回顾下上章要点: 二.摘要 本文将已架构的方式去分析分层结构中的业务层的设计,如何写出来内聚度,高耦合的业务逻辑层

系统架构师秘籍(二)软件架构- 续

上次的文章中,我们简单描述了一下软件架构的概念,接下来我们描述一下软件架构中的具体细节. 软件架构 所谓软件元素,即指组成软件系统的一个最基本的模块.一个软件元素的特性在很大程度上取决于系统的类型,以及你考虑和选取软件元素的背景和关注点.程序Lib库,子系统,可部署的颗粒或者控件(如企业级Java Bean,ActiveX 控件等),可重用的软件产品(如数据库管理系统),全部的应用程序都可以称为一个软件系统的软件元素,它取决于软件系统的构建. 一个软件元素所拥有的特点如下: 一个明确的界定的责任