大数据时代日新月异 千锤百炼好程序员

大数据时代日新月异，好技术，好知识方能与时代的高速发展并肩，不被社会所淘汰，作为一名编码的程序员深知这份工作的压力，我时刻的警醒自己，不能停止学习的脚步，要分秒必争，工作之余也要催促自己去吸取新知识，新技术。

没有想过此次学习，给了我一个全新的体验，也让我对大数据的前景更加自信，经过五个月的学习，对自身能力有了新的肯定，也重新的对大数据知识体系的整体架构有了清晰的认识，从庞杂到明了，在老师极负责任的教导下，不仅仅清晰了曾经模糊不清，百思不得其解的部分，在新技术上有了长足的发展，五月的时间虽然短暂，确十分的难忘，以下是我部分知识点的总结，希望对日后的学生有所帮助。

Zookeeper是一个“分布式协调服务”。它是一个服务进程，给分布式系统（集群）提供协调服务。也就是集群中各计算机都能和zk通信，某个计算机通过zk能感知其他计算机的状态信息。可以包括：统一配置管理(动态监听更新)，统一名称服务，主从协调，动态感知机器的上下线(watch)，集群管理（监听节点加入死亡，leader选举），分布式共享锁（最小序列），队列管理。它是一个分布式程序，意味着也需要配置集群。作为一个分布式的服务框架，也用来解决分布式集群中应用系统的一致性问题，但需注意的是有半数以上节点存活，zk就能正常服务。

zookeeper 作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是 zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理.。znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 zookeeper的核心特性，zookeeper的很多功能都是基于这个特性实现的，zookeeper使用java编写，运行在jvm上。

而这类需要提及的是HA（high avaliable）的高可用性。在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）。每个群集都有一个NameNode，如果该机器或进程不可用，整个群集将不可用。已知导致服务可靠性不高的原因是namenode节点宕机，那么怎么才能避免这个namenode节点宕机呢？一个容易想到的解决方案是部署两台namenode节点，形成主备模式（active/standby模式），这样一旦active节点宕机，standby节点立即切换到active模式。事实上HA机制就是采取的这种方案。要想实现该机制，需要解决下面这个问题，选择主备模式，而不是主主模式（active/active模式），也即让两个namenode节点都响应客户端的请求？

一个显然的前提是，两台namenode节点需要保存一致的元数据。我们知道namenode节点是用来管理这些元数据的，响应客户端请求时（上传）需要增加元数据信息，如果使用主主模式，那么两个节点都将对元数据进行写操作，怎么同步是个很困难的问题。因此，只能有一台机器响应请求，也即处在active状态的节点（可称为主节点），而另一台namenode在主节点正常工作情况下仅用来同步active节点的元数据信息，这个namenode称为备用节点（处在standby状态），可见，要解决的问题主要是怎么同步active节点的元数据信息。

五个月的学习，可以说是温故而知新，对过去的知识重新复习，加深了知识的认识深度，同时对未知的领域开始了新的探索。大数据的发展不可琢磨，对于身处其中的我们，必须时刻不挺的去追逐它的步伐，五个月收获颇丰，日后会一一记录与大家分享，以上是此时的经验总结，希望对你们有所帮助。