The final four scenarios consistent database
What is Cache
Cache speed is different. The result is a low-speed cache memory, the data is temporarily stored in the high-speed storage.
. As shown in Figure pyramid more storage above, the following can be used as a cache memory.
We in this discussion, mainly for database caching scenarios, as will redis mysql cache for the case to be.
Why we need to cache
As usual storage mysql supports full ACID properties, because of the reliability, durability and other factors. Performance is generally not high, high concurrent queries mysql will bring pressure, instability database system, while also prone to delays.
According to the principle of locality, the 80% down to 20% of the request hot data, reading and writing less scenario, the buffer layer is increased help to improve throughput and robustness of the system.
There is a problem
Data storage may occur over time, and the data in the cache would be inconsistent particular can tolerate inconsistency time, specific business needs analysis, but the usual business, we need to achieve a final agreement.
Redis as cache mysql
The usual development model, will use mysql as a cache, and redis as a cache to speed up and protect mysql. However, when the data update mysql, redis how to synchronize it.
Strong consistency synchronization cost is too high, if the pursuit of strong consistency, then there is no need to use the cache, the direct use of mysql can usually be considered are the ultimate consistency.
solution
Option One
By the key expiration time, when the update mysql, redis not updated.
In this way simple, but inconsistent very long time. If the read request is very frequent, and expired a long time, it will produce a lot of long-term dirty data.
advantage:
* 开发成本低,易于实现;
* 管理成本低,出问题概率会比较小.Disadvantages:
* 完全依赖过期时间,时间太短容易缓存频繁失效,太长容易有长时间更新延迟(不一致).Option II
In one embodiment based on the extension, through fallback key expiration time, and, when updating mysql, while updating redis.
advantage:
* 相对方案一,更新延迟更小Disadvantages:
* 如果更新mysql成功,更新redis却失败,就退化到了方案一;
* 在高并发场景,业务server需要和mysql,redis同时进行连接.这样需要损耗双倍的连接资源,容易造成连接数过多的问题.third solution
Redis performed for synchronous write optimization program two, increase the message queue, the redis update to kafka, ensure the reliability of the message queue, and then set up a consumer service to asynchronously update redis.
advantage:
* 消息队列可以用一个句柄,很多消息队列客户端还支持本地缓存发送,有效解决了方案二的连接过多问题;
* 使用消息队列,实现了逻辑上的解耦;
* 消息队列本身具有可靠性,通过手动提交等手段.可以至少一次消费到redis.Disadvantages:
* 依旧解决不了时序性问题,如果多台业务服务器分别处理针对同一行数据的两条请求,举个例子,a=1;a=5;如果mysql中十第一条先执行,而进入kafka的顺序是第二条先执行,那么数据就会产生不一致.
* 引入了消息队列,同时要增加服务消费消息,成本较高,还有重复消费的风险.Option IV
Updated by subscribing binlog redis, build our consumer services, as a slave mysql, the subscription binlog, parse out the updates, and then update to redis.
advantage:
* 在mysql压力不大的情况下,延迟较低;
* 和业务完全解耦
* 解决了时序问题Disadvantages:
* 要单独搭建一个同步服务,并且引入binlog同步机制,成本较大.to sum up
Selection program
First make sure delayed product requirements, if the delay is extremely demanding, and the data may change, do not use cache.
Generally, program 1 is enough, because the cache scheme can usually read write little scene, while the business has a certain inclusive of delay. First, there is no development costs of the program, in fact, more practical.
When the timeliness If you want to increase the update, select Option II, but no need to do to ensure retry the like.
Scenarios 3 and 4 being for delay demanding business, is a push model, a pull mode, while Option IV with improved reliability, since a lot of effort are willing to do the logical processing of the message, not as one step, with Scenario 4.
In general, a sufficient program.