hey，你机器怎么老出问题，是不是时间同步有问题呀，有问题你就直说呀，你说了我才知道时间同步有问题嘛，你不说我怎么知道时间同步有问题呢，大家要讲道理嘛，真是时间同步有问题吗，不是真的时间同步有问题吧，难道..真是时间同步有问题？
徒儿(黑人问号)：纳尼,说好的hadoop集群呢 ?
严肃脸!这是个不大起眼又比较关键的问题，一般大家对时间同步没那么敏感，但是在分布式的存储和运算当中，时间的不一致会导致获取外部节点的数据和状态错误，导致错误的相应。最典型的例子就是在分布式环境都遵循着slave-master的模式设计，从节点会定时上报自己的心跳数据到master节点，同时在master端会根据上报的消息判断是否超时，超时就是和上一次心跳的时间作为判断依据。时间不同步会被错误判断，导致回收连接 。在节点初始化之初，我们对节点的时间进行同步。
时间服务器的配置
时间服务器相对来说配置不复杂，但是倒腾下了也是蛮心塞的，只能一步一截图了：
图一：配置文件
框框部分是我们加进去的，参数解释如下:
restrict 127.0.0.1 ##授权本机可以把本机作为时间服务器进行连接
restrict -6 ::1 ##默认的授权设置
server 127.127.1.0 设置本地时钟服务器
fudge 127.127.1.0 stratum 8 设置本地时钟源的层次为8
配置完成之后，我们重启服务器,跟踪日志消息:
图二:重启和查看日志
查看时间服务器同步的情况:
图三:时间服务器的同步情况
*表示目前使用的ntp server，这里选择的本机；
st：即stratum阶层，值越小表示ntp server的精准度越高；
when几秒前曾做过时间同步更新的操作；
Poll表示，每隔多少毫秒与ntp server同步一次；
reach：已经向上层NTP服务器要求更新的次数；
delay：网络传输过程钟延迟的时间；
offset：时间补偿的结果；
jitter：Linux系统时间与BIOS硬件时间的差异时间
我们可以从图三中看到时间不断在更新,注意reach一直是0的话就有些问题了
在查看一下ntp状态,可以看到同步正常
图四:时间服务器的同状态
接下来，我们把其他节点配置时间同步，以第一台机器作为时间服务器
在客户端直接进行一次时间同步:
图五：客户端同步时间
验证没问题，我们把命令做成脚本
图六:同步时间的脚本
然后,在定时任务中进行配置
图七:配置定时同步任务
观察调度的日志,确认即可:
图八：调度的日志
接下来的事情，就是把我们的节点都配置上，这下我们的几台节点的时间都是一致的啦。
总结
这里要还原一个事实就是,时间服务器搭建是捣鼓来捣鼓去配置了几波才完成的，现在看到的配置是最后配置的样子， 刚开始配置一个是不知道啥概念，一个是不知道出错的时候怎么往下走 ，补充几点:
- 出问题多一些的地方是那个/etc/hosts的配置，需要去加上127.0.0.1的配置
- server配置的是127.127.0.1代表本机器,127.0.0.1是一个A类地址,配置的时候是用前者
- 客户端同步的时候记得关闭本机的ntpd服务 service ntpd stop
- 其他情况就是不断调整，实在不清楚就直接找师父啦
- 一般生产环境会有专门的时间服务器去同步，一般需要的是检查是否会定时同步，有的话就不用自己去倒腾了。
偷懒养成续篇
上次我们提到自动同步的事情，这里接着聊一下这个事情。我们在多台机器上面进行一些自动化的操作往往是这么几种情况:
- 需要交互式的,这种就是类似远程登录的时候需要输入密码
- 从本机同步文件到远端
- 登录远程机器执行命令
下面我们一个个解决:
我们最开始碰到的其实就是远程设置免密码登录
图九:交互式窗口
类似这种情况,我们需要引入spawn工具和expect的语法，我们可以预期一个提示输入的内容，然后进行输入，我们之前的免密码登录要修改成脚本，变成了这种样子:
图十一:期望输入
我们把用户和密码直接输入，在脚本中去匹配交互式的文本信息进行输入 ，我们写下这份脚本的时候，我们需要去授权一台免密码登录的操作就变成了这样子:
图十二:脚本方式自动面密码登录
直接就完成了，是不是特方便。
另外对于远程同步文件一般scp或者rsync都可以，ssh的命令也可以同时登录远程机器去进行执行命令，所以我们把需要做的事情全部写到一个脚本里面:
图十三:批量执行的脚本
当我们这样去做的时候，我们后面需要同步一个新的节点的话，只需要执行脚本就好了:
图十四:最终效果
