工匠解码

一直有个错觉就是，redis底层命令是并发执行的，但今天查看若干资料后发现，redis底层是单线程的，也就是说多客户端向redis服务器发送操作命令，redis底层是串行执行的，这样不禁怀疑这样不是很慢吗？后经过进一步探究，得出结论： 1 单线程并不一定比多线程慢，多线程需要不停切换上下文，本身就有性能损失 2 内存型数据库的瓶颈在IO，因为其数据本身就是在内存里面，不需要频繁的与磁盘做交互，I

公司多个系统之间经常需要相互同步数据，数据同步方式有很多种，常用的有如下几种： 1 接收方主动请求，数据提供方暴露调用接口 2 提供方主动推送，接收方被动接收其中主动推送，有有几种方式：直接调用接收方接口，通过消息中间件等。我们之前使用的rabbitMQ，但是其存在一些天生的缺陷，比如消息顺序的保证，消息的可靠性，事务消息等等。最近在看redis时，突然看到redis支持发布/订阅这种功能，感觉

multi中的命令如果有执行时报错，而不是语法错误的时候，那么exec后，正确的命令依然会执行，并不会因为其中某个命令报错而回滚。参考： https://redis.io/topics/transactions

在描述设计之前，先提出三个属性，这三个属性是实现高效分布式锁的基础。安全属性：互斥，不管任何时候，只有一个客户端能持有同一个锁。 效率属性A：不会死锁，最终一定会得到锁，就算一个持有锁的客户端宕掉或者发生网络分区。 效率属性B：容错，只要大多数Redis节点正常工作，客户端应该都能获取和释放锁。有几个疑惑：1 单实例的failover场景，如何保证一致性在我们的系统架构里存在一个单点故障，如果R

在redis.conf配置中有如下一项配置：# Set the number of databases. The default database is DB 0, you can select# a different one on a per-connection basis using SELECT <dbid> where# dbid is a number between 0 and

Redis是使用C/S模型的TCP服务器，称为请求/响应协议。 这意味着通常一个请求是通过以下步骤完成的： 1 客户端向服务器发送查询，并通常以阻塞的方式从套接字读取服务器响应。 2 服务器处理命令并将响应发送回客户端。因此，例如，四个命令序列是这样的： Client: INCR X Server: 1 Client: INCR X Server: 2 Client: INCR X