首先感谢读者朋友们一路支持和捧场，《构建高可用Linux服务器（第4版）》已面市，在当当、京东、天猫华章及亚马逊上面都售，本书较前三版改动幅度较大，具体内容可以参见下面的链接分享。
Ansible是作为自动化运维的底层实现，功能很强大，但需要通过命令或playbook的yaml文件来实现，相对对运维人员而言，学习成本过大。所以这里要考虑到通过Flask Web框架来实现其二次封装，提供HTTP接口来实现远程调用。但我们在请求Ansbile API的时候，ansible默认本身是阻塞的，用户那边会一直处于等待状态，这样大家的用户体验也不好，所以这里会用rq来实现其非阻塞功能，即实现任务的异步化。
2017年我正在看或者已经看完的书单，基本上都是纸质书，主要是长时间阅读也不伤眼。由于现阶段的主要工作是DevOps，所以涉及运维方面的书我没有再细看，主要是工作用到的话会稍为翻阅下。主要还是看开发相关方面的书，每天坚持看1-2小时书，没办法，其它时间要写业务代码或处理线上的问题，列表清如下所示：
Codis是一个分布式Redis解决方案，与官方的纯P2P的模式不同，Codis采用的是Proxy-based的方案。今天我们介绍一下Codis及下一个大版本RebornDB的设计，同时会介绍一些Codis在实际应用场景中的tips。最后抛砖引玉，会介绍一下我对分布式存储的一些观点和看法，望各位首席们雅正(黄旭东)。
为什么 Codis 比 twemproxy 慢？ Codis 追求简洁的实现，我们没有针对内存进行优化，所以会比 twemproxy 还要多一倍拷贝。 Go 虽然使用 epoll，但是 IO 都不是直接完成的，而是通过 IO thread，所以需要更多的线程间通信和线程切换。
所以在软件的正常功能开发中，并不需要去刻意的寻找消息队列的使用场景，而是当出现性能瓶颈时，去查看业务逻辑是否存在可以异步处理的耗时操作，如果存在的话便可以引入消息队列来解决。否则盲目的使用消息队列可能会增加维护和开发的成本却无法得到可观的性能提升，那就得不偿失了。（转载自知乎）
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
