目录；

关注+后台私信；资料；两个字可以免费领取 资料内容包括：C/C++，Linux，golang, Nginx ，ZeroMQ， MySQL ， redis ，fastdfs， MongoDB ，ZK， 流媒体 ，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，嵌入式 等。。。

1. 读写分离 方案

2. 强一致性和最终一致性下的解决方案

3. 缓存 出现的故障如何解决

这是最近帮朋友解决的一个架构问题

大家看先看一下这个需求，也就是看一下我们mysql的缓存问题，

他有那些应用场景，

首先需要一个网管服务器，网服务器是对应这接收客户端的链接，要求二

登陆服是多个，玩家账号数据 玩家角色数据 这两个是共通的 需要同步 ，redis只存储热点数据，redis、mysql只需要一个

这里使用redi，是为了让我们玩家可以快速的登陆，那么大家可以思考一个问题，因为在游戏业务当中我们断线重链是很平凡的，所以我们在账号登陆的时候，会反复的请求数据库，如果我们这个数据库一直在mysql这个数据，mysql压力会很大，所以我们需要在mysql前面 放一个redis来缓冲玩家的数据，这就可以让我们快速的登陆，进入我们的游戏。

解决方案

1.mysql项目中，读请求远大于写请求；经过测试读请求是写请求的大约10倍左右，有的项目可能会更多。

我们平时是怎么解决这个问题呢?

第一我们要有一个读写分离，就是利用mysql主从复制这样的原理。

这样就解决主从压力过大了，主从复制会带来什么问题？

数据不一致（所以我们必须知道主从复制的原理）

读写分离

几项重要的数据

1.内存的访问速度是碰盘访问速度的10万倍（数量级 倍率 ）;内存的访问速度大约是100ns,而一次碰盘访问大约是10ms;访问mysq时访问磁盘的次数跟b+树的高度相关；
2.一般大部分项目中，数据库读操作是写操作的10倍左右；

总结

1.由于mysqi的缩冲层不由用户来控制，也就是不能由用户来控制缓存具体数据
2.访问磁盘的速度比较假，尽量获取数据从内存中获取；
3.主要解决读的性能；因为写没必要优化，我们必须让我们的数据正确的落盘；
4.项目中需要存储的数据应该远大于内存的容量，所以我们数据获取的依据应该是mysql;
5.redis存储的只是用户目定义的热点数据；以下的讨论都是基于热点数据的同步问题；