Becomin' Charles

今天，知乎《北美码农的包子铺》专栏里，提到了，跟老板 1 on 1 聊天时讲什么的话题，文章是站在一个员工的角度讲的。

正好，最近我在做绩效面谈，我想站在 leader 或者说 mentor 角度讲讲同一个问题。这样未免有些恬不知耻，也不能涵盖所有的情况，但是我觉得说不定还是能给新人一些参考。

以前一直没有使用 zsh，理由是，这不是一个默认安装的 shell，我所工作的环境一般都是 Linux 服务器环境，一般系统默认不会安装这个 shell 的。另外，bash 我也没有使用得多熟练，为了逼自己熟练掌握 bash，不用 zsh。

简介

Rsync是一个神奇的小工具，在你的机器上设置它，非常地简单。与脚本控制的FTP会话和其他文件传输脚本不同，rsync只把那些变化的文件，压缩，并通过ssh拷贝（如果你对安全性有要求的话）。听起来很拗口，其实就是说，rsync有如下特性：

• Diffs - 只传输文件中真正变化的部分，而不是整个文件。这就使得更新更快，尤其是连接速度比较慢的时候。就算只有一个字节的变化，FTP也会传输整个文件。
• 压缩 - 文件不同的部分，会被压缩，进一步节约你的网络传输时间，降低网络的负载。
• ssh - 你可能会对安全性有所担忧。rsync数据流通过ssh协议将您的会话加密，而不是使用rsh，这也是可选的（这要求使用ssh）

Rsync远远不只一个备份/镜像工具那么简单，还提供了除上述以外的很多特性。我个人用它来同步网站目录树，从开发环境到生产环境，并且通过cron和CGI脚本自动对关键部分进行备份。以下是一些rsync的关键特性：

• 支持拷贝链接、设备、用户、组和权限
• 跟GNU的tar命令有类似的exclude选项
• 支持CVS的exclude模式，用来忽略CVS忽略的文件
• 不需要root权限
• 将文件管道传送来最小化延迟代价
• 支持匿名和认证rsync服务器

它怎样工作

你必须在两台机器中，将其中一台，通过一个很短小、简单的配置文件，设置成“rsync server”（使rsync以守护进程模式运行）。下面，我将详细描述一个范例配置文件。选项的很容易理解，并且数量很少 — 但是非常强大。

任意数量的安装了rsync的机器，都可以与运行rsync守护进程的机器同步。你可以通过这个进行备份，镜像文件系统，分发文件或者其他类似的操作。通过使用rsync算法（只传输变化部分，并且进行压缩），你将得到一个非常高效的系统。

对于没听过ssh的人来说，你应该使用它。有一个非常有用并且完整的ssh起步教程。还有访问SSH的网站。SSH为你的网络，提供了一个安全的，加密的“管道”。你应该使用它替换telnet，rsh或者rlogin，使用scp替代rcp。

设置一个Server

你必须在宿主机上设置一个配置文件，并且以守护进程的模式运行rsync。甚至你的rsync客户端机器，也可以用守护进程模式运行，以实现一个双向传输。你可以通过inet守护进程来自动地实现这个过程，也可以通过在命令行运行一个独立进程，并在后台不断重复同步。我个人用独立进程的模式运行它，就像Apache那样。我用一个crontab，每小时同步一次网站的文件夹。此外，有一个CGI脚本，在白天会经常触发rsync，立即更新网站的内容。这会造成相当多的rsync命令调用！如果你通过你的inet守护进程来启动rsync守护进程，那么每次rsync被调用，都会带来更高的负载。基本上，每有一个请求连接到你的服务器，就会重启一次rsync的守护进程。这也是为什么使用独立进程模式启动Apache而不通过inet守护进程启动的原因。如果会造成大量的rsync流量，使用独立进程模式的rsync更加快，更加高效率。反过来，如果偶尔传输一下数据，那就使用inet守护进程来触发rsync。使用这种方式，像rsync守护进程这么小的进程也不会驻留在你的内存里，如果你一天只是用一两次的话。使用哪种方式，都由你自己来定。

下面是一个rsync配置文件范例。这个文件在/etc目录下，rsyncd.conf:

1
2
3
4
5

motd file = /etc/rsyncd.motd
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
lock file = /var/run/rsync.lock

#模块名
[simple_path_name]
path = /rsync_files_here #模块路径
comment = My Very Own Rsync Server
uid = nobody
gid = nobody
read only = no
list = yes
auth users = username #rsync用户名
secrets file = /etc/rsyncd.scrt #rsync密码
上面加了注释的地方，都是你在开始使用时候，需要修改的。我现在从上到下，逐行过一遍。上面的范例，配置的是一个rsync传输到那台机器上的路径。

前面四行，是rsync以守护进程方式运行，所需要指定的文件和它们的路径。motd代表今日消息（message of the day），就像你FTP服务器使用的欢迎语一样。当客户端连接到这个服务器的时候，这个文件的内容会显示出来。一般用于欢迎语，警告，或者简单的识别用途。下一行，设定了一个日志文件，用于保存诊断信息还有正常的运行时消息。PID文件包含了rsync守护进程的进程ID。锁文件用于保证所有的事情都平滑运行。这些配置是rsync守护进程的全局配置。

下一块内容，设定了rsync使用的路径。下面的选项只对这个模块起作用。模块名，就是一个目录的别名或者简写，并不是完整的路径。应该短小，易记并且容易输入。下面是你应该设置的最重要的东西：

• path - 文件系统中的绝对路径
• comment - 路径的简短说明
• auth users - 这是有权使用这个路径的用户名列表，逗号分隔，不需要是系统的真实用户
• secrets file - 存放用户名密码的文件，内容是键值对，如:user:password

hosts allow和hosts deny是主机白名单和黑名单，可以通过主机名或者ip地址限制使用这个路径的机器。如果没有这两个选项，你的这个目录就像全世界使用rsync的进程公开了。我觉得这是应该避免的。

查看rsyncd.conf的手册，尤其是那些关于安全的选项。你可不希望任何人用rsync传上来一个空目录，并且使用–delete选项吧（所有东西删光）？

其他所有的选项，手册里都会解释。基本上，上面的选项配置了上传的文件都会被改变归属为uid/gid，文件系统的路径path是可读写的，rsync的path会出现在rsync列表中。rsync secrets文件我也放到了/etc目录下，和motd一起，并且都用rsyncd开头，让它们好辨识一点。

使用Rsync

在网络上使用Rsync

首先安装一些依赖的软件包：

1
2
3
4
5
6
7

yum install libmcrypt.x86_64 libpng.x86_64 libjpeg-turbo.x86_64 \
libxml2.x86_64 readline.x86_64 libxml2-devel.x86_64 openssl.x86_64 \
openssl-devel.x86_64 libcurl-devel.x86_64 libjpeg-turbo-devel.x86_64 \
libwebp-devel.x86_64 libpng-devel.x86_64 freetype-devel.x86_64 \
libmcrypt-devel.x86_64 readline-devel.x86_64 gcc.x86_64 pcre-devel.x86_64

然后是正确的配置 PHP7 的编译选项

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

./configure -C \
--prefix=/usr/local/php \
--with-readline \
--with-curl \
--with-gd \
--with-iconv \
--with-gettext \
--with-mcrypt \
--with-mysqli \
--with-openssl \
--enable-pcntl \
--enable-soap \
--enable-mbstring \
--with-zlib \
--enable-fpm \
--with-freetype-dir=/usr \
--with-jpeg-dir=/usr \
--with-webp-dir=/usr \
--with-png-dir=/usr

最后执行编译指令：

1
2
3
4
5

#使用2个核的意思，看CPU多少决定这个参数
make -j 2
make install

编译完了，要单独编译一下 opcache，虽然我觉得这个应该编译进去到 PHP 解释器里面，
但是目前，我只找到了以扩展方式使用的方法。

1
2
3
4
5
6
7

cd ext/opcode
/usr/local/php/bin/phpize
./configure --with-php-config=/usr/local/php/bin/php-config
make -j 2 
make install

然后编辑配置文件，添加：

1

zend_extension=opcache.so

=====

下面是 PHP 5 的编译脚本：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#!/bin/bash

yum -yq install  \
libxml2-devel.x86_64 gcc.x86_64 \
openssl-devel.x86_64 libcurl-devel.x86_64 libjpeg-turbo-devel.x86_64 \
libwebp-devel.x86_64 libpng-devel.x86_64 freetype-devel.x86_64 \
libmcrypt-devel.x86_64 readline-devel.x86_64 libtool-ltdl-devel.x86_64

./configure -C \
--prefix=/usr/local/php \
--with-readline \
--with-curl \
--with-gd \
--with-iconv \
--with-gettext \
--with-mcrypt \
--with-mysqli \
--with-pdo-mysql \
--with-openssl \
--enable-pcntl \
--enable-soap \
--enable-mbstring \
--with-zlib \
--enable-fpm \
--with-freetype-dir=/usr \
--with-jpeg-dir=/usr \
--with-png-dir=/usr

因为网络原因，可能导致某些静态文件无法被用户直接访问到，我这里提供一种解决方案。

你手下有一群很棒的工程师，并且，他们想要在自己的职业生涯中更进一步。由于他们付出的努力，他们的团队在成长，而你，想要对他们的工作成果有所表示，最显而易见的一个方式，就是让他们负责管理他们自己创建的团队，尤其，他们已经是团队的事实上的 Leader 了。但是，这真的是他们想要的么？或者只是他们所相信的“自己应该想要的”？

当我在使用git的时候，有三个东西的出现，一度让我非常困扰，就如题所述，staging，index，和cache。

之前，我写了一篇文章《SVN为什么比git更好》，主要是从非常朴实和现实的角度，从一个为全团队选型的角度，分析了为什么SVN比git更好。但是公私分明，作为我个人来说，我想我还是更喜欢git的。

下载了《生活大爆炸》打算重温，但是文件名实在是太过长了啊，受不了啊！

首先我表明一个根本的立场，我个人更喜欢用git，但是，这仅仅是一个个人偏好。当我们需要将一种技术方案带给整个团队的时候，并不是由我们的个人偏好作为主要决定因素，而应该充分去权衡利弊，选择对团队，对公司更有效率的方案。抛开个人立场，理性评估利弊，可能才是我认可的一个资深程序员，或者一个架构师的本分。

我所在的团队，现在选用的技术方案是git作为全公司的版本控制系统，我们一共有差不多20个程序员，使用五种以上的程序设计语言，研发维护四个左右的项目，属于小型创业公司中，研发规模中等偏上的企业。使用git作为版本控制系统，在我加入公司之前，已经是既成事实了，在我听说这一点的时候，我非常高兴，因为我说过，我喜欢git。

上周五，我们公司新来的工程师，在周会上分享git，有个同事挑战道，为什么git比svn更好？这个问题，如果是问我个人的话，我可能会有很多的理由，但是，就像我一贯的思维模式，说服别人的时候，必须给出足够令人信服的原因，不能使用主观因素去说服别人，那样只能引起争论。

对于，“为什么git比svn更好”这个问题，我真的很想给出一个肯定的答案，但是，我在探寻答案的过程中，遇到了困难。于是，我来尝试一下站在反面的立场来给出一份答卷，然后，我们再反过来辩论，于是就有了本文的题目。