性能优化的第二篇文章，将重点讲一下Redis 的响应延迟，响应延迟如何对redis 进行优化。这个延迟不是说一个命令或者几个命令变慢了，延迟了几秒，就说Redis 变慢了。在不同的软硬件环境下，Redis 本身的绝对性能并不相同。要根据Redis 的基线性能做判断。所谓的基线性能呢，也就是一个系统在低压力、无干扰下的基本性能，这个性能只由当前的软硬件配置决定。怎么确定基线性能呢？

为了高可用，生产环境我们的服务都是以集群的方式对外提供服务，集群的ip随时可能变化，比如重启，发布，扩容等。我们也就需要用一本 “通讯录”去保存和更新服务的节点，而这个通讯录就是注册中心，注册中心在整个微服务架构中是必要的。既然是微服务机构，那么必然有客户端和服务端。对于注册中心来说，服务端启动完成的时候注册服务，客户端就是订阅服务

在业务上，对数据的更新是非常频繁的，mysql 来说就是一条update 语句。大家有没有感觉update 语句对普通索引的更新总是很快，这是为啥呢？是不是很好奇更新语句的执行流程是怎么样的呢？由于语句执行错误，数据被污染，我们会让DBA 帮我们恢复到更新前的状态，这又是怎么完成的呢？对于这些问题，会在接下来的文章详细讲解，本章引擎是innodb 引擎。为了方便讲解，我将画一个流程图，这个流程图包