为何单线程的 Redis 却能支撑高并发？
为什么 Redis 中要使用 I/O 多路复用这种技术呢？
首先，Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的。
相关分享
ThinkPad + Redis：构建亿级数据毫秒级查询的平民方案
如何用普通设备实现海量数据的毫秒级查询？文章分享了在 ThinkPad 上构建 Redis 系统的完整方案，详细解析了数据分片、查询优化和资源调配等关键技术，还提供了针对高效查询的实际案例。轻量化实现，高性能表现，为开发者提供了实用的参考思路，值得深入学习！
无图
图解Blink-Tree：B+Tree的一种并发优化结构和算法
本文介绍了 Blink-Tree，这是一种 B+Tree 的并发优化结构。通过引入 high key 和 link 指针，解决了并发访问时的性能问题，特别适用于高并发环境的存储引擎优化。如果你对数据库存储引擎感兴趣，这篇文章不容错过！
无图
无图
Redis高可用原理
Redis中为了实现高可用（High Availability，简称HA），采用了如下两个方式：
1、主从复制数据。
2、采用哨兵监控数据节点的运行情况，一旦主节点出现问题由从节点顶上继续进行服务。
无图
高效I/O并发处理：双缓冲和Exchanger
双缓冲(double buffering)是高效处理I/O操作的一种并发技术，它使用两个buffer,一个goroutine使用其中一个buffer进行写，而另一个goroutine使用另一个buffer进行读，然后进行交换。这样两个goroutine可能并发的执行，减少它们之间的等待和阻塞。
本文还提供了一个类似Java的java.util.concurrent.Exchanger的Go并发原语，它可以用来在两个goroutine之间交换数据，快速实现双缓冲的模式。 这个并发原语可以在github.com/smallnest/exp/sync/Exchanger找到。
无图
无图
浅谈Redis分布式锁(上)
不论面试还是实际工作中，Redis都是避无可避的技术点。在我心里，MySQL和Redis是衡量一个程序员是否“小有所成”的两把标尺。如果他能熟练使用MySQL和Redis，以小化大，充分利用现有资源出色地完成当下需求，说明他已经成长了。
本篇文章我们一起来探讨Redis分布式锁相关的内容。
说到锁，大家第一时间想到的应该是synchronized关键字或ReentrantLock，随即想到偏向锁、自旋锁、重量级锁或者CAS甚至AQS。一般来说，我不喜欢一下子引入这么多概念，可能会把问题弄复杂，但为了方便大家理解Redis分布式锁，这里稍微提一下。
无图
协程和线程的历史
昨天运营商线路出了问题，体验了一把电话线拨号上网一样的网速。
打开浏览器是这样的场景：
先白屏一会儿。
逐渐显示出网页上的全部文字。
卡一会儿。
慢慢地把网页上的所有图片显示出来。
正在无聊地等待网页加载的时候阴差阳错地意识到浏览器这种一边渲染一边下载的工作方式在历史上还促成了协程和线程这一概念的产生。那么就来讲一讲故事吧。
无图
Go单线程运行也会有并发问题
一个Go大佬群中严肃的讨论了一个问题：Go程序单线程多goroutine访问一个map会遇到并发读写panic么？
答案是肯定的，因为出现了这个问题所以大家才在群中讨论。
为什么呢？因为单线程意味着并行单元只有一个(多线程也可能并行单元只有一个)，但是多goroutine意味着并发单元有多个，如果并发单元同时执行，即使是单线程，可能就会产生数据竞争的问题，除非这些goroutine是顺序执行的。
无图
Rust并发编程番外篇: Mutex内部实现
Mutex是最常用的一种同步原语，它提供了互斥锁的功能,多线程可以互斥访问共享数据以及通过锁保护临界区。Rust标准库提供了Mutex的实现，接下来我们看看它是怎么实现的。
无图