其中keeper主要负载请求的鉴权、认证缓存，以及读写请求数的统计，是云数据库权限校验，负载均衡和计费功能实现的核心模块。同时，keeper还对事务类的请求进行了优化，通过一致性哈希和缓存会话，keeper会将不同事务的请求压力分摊到agent模块，提供更好的事务使用性能。
agent模块则有下面几大功能：
一是维护接入层到底层数据库实例的连接池，通过复用已建立的连接来减少请求鉴权和连接创建的耗时。二是统计请求的并发数，对读写请求的QPS进行平滑处理，避免短时间的毛刺影响数据库性能和可用性。三是对热迁移的优化，通过agent模块，我们会在热迁移切换数据库实例时，将请求挂起，切换后再将请求恢复这种方式，实现热迁移过程对用户的全程无感知。
读写请求通过了接入层，再接下来会进入到我们的存储层进行数据库实例的读写。而我们的数据库实例在设计上具有如下几个特点：
一、为了保证数据库的高可用，我们的每个数据库实例都是由一个副本集整体来进行服务。
二、数据安全性方面，我们使用了一致性算法来保证副本集数据的最终一致性。通过定期备份支持用户将数据回档到指定时刻。
三、我们也充分利用云数据的日志、监控、拨测等模块收集的信息，对云数据进行了自动化的运维的相关设计，对常见数据库异常进行秒级探测和自动处理，保证用户业务平稳运行。
云开发数据库设计与优化那么，围绕云开发数据库，我们做了哪些特性优化呢？
访问控制优化首先是权限控制方面。用户只能访问自己的数据库,所有连接必须认证，用户无法访问其他用户的数据库。但可以在自己的数据库上建立多个不同权限的账户（比如建一个只读的账户）。当然有了微信全链路免鉴权的特性，这里用户不需要太关心认证问题。
其次是连接数控制方面。我们会分两层进行控制：
1）在接入层进行客户端连接控制，根据初始化时实例类型（免费/付费等）进行不同的初始化限制，如果超过限制则提示相应的用户；
2）接入层到存储层也有相应的连接数控制，会池化到后端数据库所有主从节点的链接，避免因过多链接而导致的数据库性能问题。
最后是机器层面的出入流量控制以及资源使用限制，原理与连接数控制类似。用户所有的请求都会经过接入层，因此可以在接入层控制qps进而实现后续的按量付费功能。qps超过阈值后可以提示用户或者在接入层做排队处理。
PS：有人可能会质疑了，这里不是弹性伸缩的嘛？为何还有qps的限制呢？不应该是我qps越来越高，后端的数据库资源也跟着不断扩容嘛？
是的，默认的配置下会有一定弹性扩展空间，但是会有一个限制。当然，这里限制具体多少跟产品策略有关。
数据安全优化数据安全是数据库最重要的特性之一。毕竟一个存在丢数据风险的数据库并不可能在市场激烈的竞争中活下来。那么云数据库是如何保证数据安全的呢？
1）分布式多副本容灾。云开发数据库底层默认三副本，即一份数据会存储三份放在不同的机器上。节点区分主从状态，主节点可写可读，从节点只读。存储节点之间采用raft-like的副本集协议来实现三副本数据的最终一致性。另外，所有到数据库的连接必须认证以及所有数据均加密压缩存储这两点保证了数据的链路安全以及存储安全。
2）高可用。当机器发生故障时副本集内的数据节点会自动切换（FailOver），从节点变为主节点继续提供服务，将对业务的影响降到最低。
3）备份/回档能力。备份对用户完全透明，后台根据数据库的状态自动选择性地进行全量以及增量备份；支持7天内任意时间回档，可以选择只回档单个库表，大大减少回档所需的时间。
另外，如果节点故障需要新加一个节点到副本集中，可选择从备份文件中进行恢复，减少对源集群的侵入性。