Building a Consistent Hashing Ring Part3-Part5(构建一个一致性哈希环 Part3-Part5)
本篇是Building a Consistent Hashing Ring 第三到第五部分的翻译,上篇翻译了原文的第一到第三部分,在第三到第五部分中,引入了分区概念,多副本,多可用区,以及权重的概念,更加接近一个高可用的实际一致性环
本篇是Building a Consistent Hashing Ring 第三到第五部分的翻译,上篇翻译了原文的第一到第三部分,在第三到第五部分中,引入了分区概念,多副本,多可用区,以及权重的概念,更加接近一个高可用的实际一致性环
本篇是Building a Consistent Hashing Ring的翻译,原文一步步描述了一个一致性哈希环的构建过程,对于OpenStack Swift存储,对应的Ring文件,其实就是一个一致性哈希环。
这篇文章讲述了OpenStack Swift Ring文件的构建原理。目前翻译了第一部分和第二部分,包含了最原始的算法,并最终引入虚拟节点,减少扩容时的数据移动
ArchLinux下网易云音乐会有偶然的白屏情况,是由于不支持某些emoji字体导致的,可以安装noto-fonts-emoji
,然后配置一下字体即可解决:
sudo pacman -S noto-fonts-emoji
配置~/.config/fontconfig/conf.d/51-noto-color-emoji.conf
文件:
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<selectfont>
<acceptfont>
<pattern>
<patelt name="family"><string>Noto Color Emoji</string></patelt>
</pattern>
</acceptfont>
</selectfont>
<match target="font">
<test name="family">
<string>Noto Color Emoji</string>
</test>
<edit name="scalable" mode="assign"><bool>true</bool></edit>
<edit name="embeddedbitmap" mode="assign"><bool>true</bool></edit>
<edit name="hinting" mode="assign"><bool>true</bool></edit>
<edit name="hintstyle" mode="assign"><const>hintfull</const></edit>
</match>
<match target="pattern">
<test name="family" qual="first" compare="contains">
<string>emoji</string>
</test>
<edit mode="assign" name="color">
<bool>true</bool>
</edit>
<edit mode="assign" name="family">
<string>Noto Color Emoji</string>
</edit>
</match>
<match target="pattern">
<edit name="family" mode="prepend">
<string>Noto Color Emoji</string>
</edit>
</match>
</fontconfig>
在使用普通用户执行需要超级用户权限的指令时,经常忘记前面加上sudo,等到命令输入完成,再加sudo很麻烦,可以绑定一个快捷方式快速输入最前面的sudo:
如果使用Bash,在~/.bashrc
中加入:
bind '"\e\e":"\C-asudo \C-e"'
如果使用Zsh,在~/.zshrc
中加入:
bindkey -s '\e\e' '\C-asudo \C-e'
生效后,只需要连续按两下ESC
键,即可快速将sudo添加到命令最前端。
上一次说到Zend的词法分析,现在该轮到语法分析和中间代码生成部分了。一般情况下,词法分析和语法分析是在一起的过程,所以一般词法分析器和语法分析器是交织在一起的,共同运行。
PHP的语法分析器使用的是Bison
。具体的语法分析器定义在 Zend/zend_language_parser.y
文件中。
本来这篇分析是作为一次内部分享而写的,然后就懒癌发作,一直没有写完,到目前也只是写了大约三分之一吧,原因之一也是PHP深入下去还是比较复杂的。最近空闲下来,还是觉得应该把这篇都写完吧。
手动分割线===================
一段PHP脚本,到底最终是如何执行的呢?我们可以通过下面这一段最简单的代码,PHP的HelloWorld,看一步步看看到底PHP是如何执行的。
<?php
echo 'Hello ' . 'World';
echo 'Hello ', 'World';
?>
为啥要输出两次呢,当然是刻意构造好的,下面需要用的到 :-)
在Linux系统上支持对用户以及对用户组设置磁盘配额的文件系统很多,常见的Ext4文件系统对配额的支持就很好,但是如果要针对某个目录进行配额限制的话,就比较难办了。
至少在Ext4文件系统上并没有什么好的办法,有些比较hack的办法,比如使用 fuse
挂载一个目录,并在这个文件系统里实现目录级别的配额,虽然可以实现,但是问题就是 fuse
的性能要差很多。
然后调查了一下XFS,XFS文件系统支持 Project Quota
功能,通过该特性,可以支持目录级别的配额限制。
服务器的Apache进程突然无法启动了,在错误日志中,有如下信息:
[Mon Feb 13 14:54:10 2017] [emerg] (28)No space left on device: Couldn't create accept lock (/var/logs/accept.lock.8173) (5)
[Mon Feb 13 14:55:02 2017] [emerg] (28)No space left on device: Couldn't create accept lock (/var/logs/accept.lock.8823) (5)
[Mon Feb 13 14:56:01 2017] [emerg] (28)No space left on device: Couldn't create accept lock (/var/logs/accept.lock.9113) (5)
[Mon Feb 13 14:57:01 2017] [emerg] (28)No space left on device: Couldn't create accept lock (/var/logs/accept.lock.9765) (5)
看了一下磁盘,空间并没有被占满,于是搜索了一下,找到了办法。
Monitor部署结束后,需要部署Ceph的OSD,OSD是Ceph实际存储的核心,有了OSD,数据才能正常进行存储,这里还是在一台机器上部署3个OSD,实际生产环境中,会有更多的OSD以及更多的机器。
这里默认机器上已经装好了所有Ceph对应的包。出于简单考虑,所有的OSD只分配一个对应的数据目录。实际生产环境中,一般一个OSD会对应一个设备。
Ceph官网上介绍了使用ceph-deploy工具部署Ceph集群的方法,但是手工部署的方法文档中写的不够详细,花了点时间研究了一下,下面是手工部署一个简单的Ceph集群的步骤,先说怎么部署Monitor。
Monitor是Ceph的核心,用于存储所有的元信息,这里部署的是一个3 Monitor的集群,出于简单考虑,这三个Monitor被我放在了同一台机器上,实际部署的话,还是要放在不同的机器上保持高可用。