缓存穿透/击穿/雪崩 - 解决方案分析
设计一个缓存系统,不得不要考虑的问题就是: 缓存穿透、缓存击穿与失效时的雪崩效应。
设计一个缓存系统,不得不要考虑的问题就是: 缓存穿透、缓存击穿与失效时的雪崩效应。
从生产者消费者模型探究回顾golang channel注意事项; 实例探究no buffer及buffer channel;
事务指的是满足ACID
特性的一组操作,mysql
中可以通过commit
提交一个事务,也可以使用rollback
进行回滚。 在并发场景中很难保证事务的Isolation
特性, 即无法保证临界资源的排它性操作, 从而引发数据一致性问题, 临界资源互斥问题显然需要借助加锁来解决, 在并发事务中就需要用锁的并发控制来处理;
为深入学习了解redis
, 本文将对redis5.0.0
源码包目录下的redis.conf
配置文件进行完整翻译学习, 翻译顺序与配置文件保持一致;
在生产环境中需要用到redis
做数据持久化落地数据库时, 一般应搭建专属的redis
集群来避免单点故障及单点读写性能问题, 如不是重度redis
用户, 数据量压力不是特别大时, 也可以考虑采用redis
主从同步架构代替, 本文将试图对redis
主从同步原理, 步骤, 配置项, 实践等方面进行学习总结;
通过示例分析,深入了解redis
数据持久化策略执行机制;
为了确保连续多个操作的原子性, 一个成熟的数据库通常都会有事务支持, Redis
也不例外, Redis
通过MULTI
, DISCARD
, EXEC
, WATCH
和UNWATCH
五个命令来实现事务功能;
用redis管道技术
对执行结果没有互相依赖,对结果响应也无需立即获得的命令集批量提交到redis
服务器的方式,能在一定程度上提升redis
性能,性能提升的原因主要是TCP连接中减少了交互往返
的时间。
redis
提供两种方式进行持久化,一种是RDB
快照持久化(原理是将Reids在内存中的数据库记录压缩后定时dump到磁盘上的RDB
持久化,存储紧凑),另外一种是AOF
(append only file)持久化(原理是将Reids的操作日志以追加的方式写入文件), AOF
日志在长期的运行过程中会变的无比庞大,数据库重启时需要加载AOF
日志进行指令重放,这个时间就会无比漫长。所以需要定期进行AOF
重写,给AOF
日志进行瘦身。
Redis的客户端与服务端采用一种叫做RESP(REdis Serialization Protocol)
的网络通信协议交换数据。 这种协议采用明文传输,易读也易解析。Redis
客户端采用此协议格式来对服务端发送不同的命令,服务端会根据具体的操作而返回具体的答复。客户端和服务端采用的是简单的请求-响应
模型进行通信的。