这里的 IO，是指的读取外存（硬盘）的次数。
数据库使用树做索引是因为可以范围查找，而搜索树中， IO 的次数跟树的高度相关，为什么这么说呢？
通常树中的一个节点大小和数据库中的 page 大小存在关联， 而数据库是按 page 读取数据的，可以简单理解，数据库可以一次 IO 读取一个节点的数据。在搜索树的查找中， 要查询多少个节点就是多少次 IO， 为 log(h), h 是树的高度。
由于 page 的大小有限，我们希望每个节点，可以多存储一些 key （分割点）的个数， 节点中的 key 多了， 代表子树可以有更多的分支， 这就会降低树的高度。B 树中节点不仅保存了 key 还保存了节点的 Value ， 而 B+ 树中非叶子节点只保存 key， 所以能存储更多的 key。
如此这样减少高度， 减少 IO 次数。
另外，B+树的叶子节点形成了一个有序链表，这使得范围查询变得更加高效，因为可以顺着叶子节点的链表进行遍历，而不需要回溯非叶子节点。
本文系从老博客平台迁移过来， 最初写于2018-07-08
BIND软件一般linux发行版都自带，如果没有安装，如下安装：
yum install bind -ybind 配置路径在
[root@lyx156 ~]# ls /etc/named
named/ named.iscdlv.key named.root.key
named.conf named.rfc1912.zones本文系从老博客平台迁移过来， 最初写于2018年06月5日
keepalived 用于高可用，
haproxy 用于负载均衡
下列中：
192.168.0.203:7480 192.168.0.202:7480 是真实网关服务节点 （RGW） 192.168.0.205 192.168.0.204 是负载均衡器 （LB） 192.168.0.200 是用于负责均衡器间的高可用的虚拟ip （VIP）
架构示意图如下：
本文系从老博客平台迁移过来， 最初写于2018-02-11 22:37:15
最近在配置多站点的时候，想了好久， 有一个纠结的地方是：
由于在异地有两套或两套以上的集群，在配置多站点同步前，需要在主zone上创建一个网关系统用户用于同步，数据的读取都是依赖这个用户的权限。可是时间久了（或者说换了个管理员）， 我怎么找到当时配置多站点的时候用的是哪个网关用户呢？也就是用的这个同步的用户的用户id是多少呢，看官网文档的意思是，固定一个用户id 用做多站点同步，固定一个用户id就要求，这个固定的id 没有之前没有被占用，
本文系从老博客平台迁移过来， 最初写于2018-01-27 12:04:52
目前web应用兴起，不仅可以在桌面上浏览操作，也可以轻松适配到移动端浏览操作后台系统。
为已有后台系统，开发web管理平台。在设计上有一个困扰就是，web应用获取系统状态信息是实时获取，还是截取前端用户输入值操作成功后保存在数据库，下次直接读取数据库？可谓两种方法都有利弊，实时获取，就是一次收集的信息量太大，前端页面等待的时间太长， 用户体验不好，优点是：通过web页面看到的系统状态信息与不通过web端直接操作系统后台是一致的。第二种方法：优点：开发流程简单，web页面获取信息快。缺点是：当不通过web端直接系统后台上操作的结果是反应不在web端上的。