开发者社区> 余二五> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

多核计算与并发编程(四) 缓存数据同步的设计

简介:
+关注继续查看

   这次讲一个完整的例子,我们就做一个打折加油站信息一览,功能是浏览油价打折的加油站,以及当前的汽油价格。

   我们这个网站的访问量非常大,一台服务器是不够的(否则我们就不需要在多台服务器间同步数据了不是吗),甚至于给我们提供加油站信息的人也非常多,录入数据也需要多台服务器,于是我们有了下面的服务器的架构

213034761.jpg

   我们有一台数据库服务器,也许将来是多台,但是不在本文的讨论范围。

   我们有两台用于数据维护(录入、修改)的服务器,我们称之为“写服务”。我们有三台缓存服务器,把数据库里面的数据全部加载到内存中,提高服务响应的速度,给网站和手机端使用,我这里称为“读服务”。


我们思考以下问题:

   1.“写服务”使用中,如果用户录入数据时连接到不同的服务器(A和B),行为和结果会不同吗?

   2.“写服务”引起的数据改变,怎么通知到“读服务”去更新缓存中的数据?

   3.“读服务”使用中,如果用户录入数据时连接到不同的服务器(C、D、E),行为和结果会不同吗?


现在回答上面的问题

   1.“写服务”没有数据缓存,用户所有的操作都是直接和数据库打交道,所以,所有服务器的行为都是一致的,用户连接到服务器A或者B,没有任何差别。

   2.这里我使用一个简单的方法来实现,到“写服务”引起数据变化后,把数据变化的条目id,追加到一个记录数据变化的队列中。“读服务”的服务器各自定时查询数据变化的队列,从数据库读取对应的记录来更新自身的缓存。

   3.“读服务”的服务器C、D、E各自定期更新缓存,会有数据不一致的情况,取决于“定期”更新的间隔,用户连接上不同的服务器,可能会查询到不同的数据,在大多数应用中,这是可以容忍的。

现在讲一讲数据同步的具体实现


1.消息约定

   在我们的应用中,只有一种消息,就是“数据变化”,参数是数据库中变化数据的id,“写服务”在任何操作后,都发送“数据变化”消息。

   “读服务”收到消息后,去数据库查询对应的记录,有三种情况。

   a.数据库查到记录,缓存中没有,可能是“写服务”进行了添加操作。“读服务”把记录添加到缓存中

   b.数据库查到记录,缓存中也有,可能是“写服务”进行了更新操作。“读服务”更新缓存中的记录

   c.数据库没有,缓存中存在,可能是“写服务”进行了删除操作。“读服务”删除缓存中的记录

这一消息约定的优点是,即是消息重复执行,也不会造成数据错误


2.消息队列

   我使用数据库的一个表,来作为消息队列,每个消息有自动增加的id,和创建时间。自动增加id是给消费者(“读服务”)避免重复消费已经消费过的消息。创建时间用于定时批量删除过期的消息


3.消费消息

   “读服务”定时查询消息表,消费消息(更新缓存)之后,记录最后的id,避免下次重复获取


4.“读服务”重启

   当服务重启的时候,所有的数据都是从数据库读取的最新数据,但也有可能在加载数据的过程中,有新的数据变化。解决办法是,

   在启动的最初,记录消息队列最大的消息id,在启动完成后,已刚才获取的最大id,作为首次获取消息的起始值(但不包括那个最大id),如果在启动过程中,消息队列有了新id,将不会错过。


总结一下,这个方案

   优点:实现简单,读服务器之间不需要有数据交换,所有的服务都各自访问消息队列。

   缺点:使用消息轮询,数据加载会有延后,延后的时间取决于轮询的间隔。











本文转自 ponpon_ 51CTO博客,原文链接:http://blog.51cto.com/liuxp0827/1344918,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
系统性能百倍提升典型案例分析:高性能队列Disruptor
Disruptor 是一款高性能的有界内存队列,目前应用非常广泛,Log4j2、SpringMessaging、HBase、Storm 都用到了 Disruptor,那 Disruptor 的性能为什么这么高呢?
0 0
《性能优化》并发与并行
性能优化系列第一篇主要给大家科普了一些性能相关的数字,为大家建立性能的初步概念。第二篇给大家介绍了支撑淘宝双十一这种达到百万QPS项目所需的相关核心技术。 本文带来的是性能优化中的第一利器:并发与并行。
0 0
实战并发-使用分布式缓存和有限状态机
实战并发-使用分布式缓存和有限状态机
0 0
【高并发】32位多核CPU并发读写long型数据为何会出现诡异问题?看完这篇我懂了!
诡异的问题 我们在32位多核CPU的计算机上以多线程的方式读写long类型的共享变量时,线程已经将变量成功写入了内存,但是重新读取出来的数据和之前写入的数据不一致,这到底是为什么呢? 原因分析
0 0
分布式、高并发、多线程,到底有什么区别?
当提起这三个词的时候,是不是很多人都认为分布式=高并发=多线程? 当面试官问到高并发系统可以采用哪些手段来解决,或者被问到分布式系统如何解决一致性的问题,是不是一脸懵逼? 确实,在一开始接触的时候,不少人都会将三者混淆,误以为所谓的分布式高并发的系统就是能同时供海量用户访问,而采用多线程手段不就是可以提供系统的并发能力吗?实际上,他们三个总是相伴而生,但侧重点又有不同。
1179 0
并发基础
1: 并发的简短历史
1219 0
《深入浅出DPDK》—第3章3.2节指令并发与数据并行
前面我们花了较大篇幅讲解多核并发对于整体性能提升的帮助,从本节开始,我们将从另外一个维度——指令并发,站在一个更小粒度的视角,去理解指令级并发对于性能提升的帮助。
1240 0
Greenplum 资源隔离的原理与源码分析
背景 Greenplum是一个MPP的数据仓库系统,最大的优点是水平扩展,并且一个QUERY就能将硬件资源的能力发挥到极致。 但这也是被一些用户诟病的一点,因为一个的QUERY就可能占光所有的硬件资源,所以并发一多的话,query相互之间的资源争抢就比较严重。 Greenplum资源隔
7754 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
分布式高并发缓存6.0
立即下载
Redis多线程性能优化
立即下载
PostgresChina2018_桑栎_PipelineDB体系结构和使用场景(1)
立即下载