我们在申请上游读接口调用权限时，往往会多问一句，这接口是否支持批量查询。正所谓，能批量绝不单个，能异步绝不串行。而读接口的底层大部分是通过Redis的批量Mget查询实现，没有人敢放心地将数据库查询暴露给非内部的系统。
但是，每次查询Key的个数如果不加以控制的话，将是一个隐患。比如，元素数目从10增长到100这个过程中，Mget性能下降非常明显。
因为，Mget是一个多Key的操作命令，但是一次操作的N个Key不在同一个分片上的话，就会将Mget命令拆分成多个Mget命令，也就是说一个请求将会被放大再合并。这是底层实现引起的限制。
这就好比，在分库分表的场景中，如果你想对不在一个数据库的多表进行事务操作，神仙也无能为力。唯一的办法就是只有场景合适时才使用，或者努力创造机会。比如，算出Key对应的节点，将Mget操作手动分成多个操作，减少在Redis系统中的Merge操作。
不过呢，当列表为空时，客户端如果一直无脑轮询进行空运转的话，浪费资源。列表中有值能主动通知客户端来取就好了，类似并发编程模型的生产者和消费者模型。幸运的是，Redis就提供了这种特性，借助Blpop命令，可以移出并获取列表的第一个元素，如果列表没有元素会阻塞等待。
但是，线程一直阻塞在那里的话，客户端连接就会成为闲置连接，闲置过久，服务一般会主动断开连接，这个时候再操作就会抛出异常。所以，在使用阻塞队列时，要考虑等待超时的问题。
Redis这种单线程模型能达到这么高的性能，很多功劳都是内存贡献的，但是我们也不能无视某些内存机制对性能的影响。
我们知道，虚拟地址和内存地址是需要转换的，转换过程要查映射表，cpu通过内建快表TLB加速这个查表过程。
如果虚拟页越大，表的条目数就越小，命中率就越高。所以，主流操作系统都提供了内存大页机制Huge Page，允许我们定制超过4K的大内存页。
但是，对于Redis这种需要Fork子进程的系统来说并不友好。Redis主从同步是异步进行的，保证了最终一致性，而Fork子进程那个瞬间是阻塞主线程的。
如果映射表和内存页太大，拷贝就会很慢，阻塞时间将变得更长。因此，在生产环境，通常会关闭内存大页机制。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
