leixin 发布的文章

这里的 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 -y

bind 配置路径在

[root@lyx156 ~]# ls /etc/named
named/               named.iscdlv.key     named.root.key
named.conf           named.rfc1912.zones

- 阅读剩余部分 -

本文系从老博客平台迁移过来, 最初写于2018年06月5日

0. 说明

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端上的。

- 阅读剩余部分 -