一面 10-11 14:30 牛客 1v1 30min
简介：
WAL(Write-Ahead-Log)预写日志是Hbase的RegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志。在每次Put、Delete等一条记录时，首先将其数据写入到RegionServer对应的HLog文件中去。
客户端向RegionServer端提交数据的时候，会先写入WAL日志，只有当WAL日志写入成功的时候，客户端才会被告诉提交数据成功。如果写WAL失败会告知客户端提交失败，这其实就是数据落地的过程。
在一个RegionServer上的所有Region都共享一个HLog，一次数据的提交先写入WAL，写入成功后，再写入menstore之中。当menstore的值达到一定的时候，就会形成一个个StoreFile。
解决的问题：
HBase的Write Ahead Log (WAL)提供了一种高并发、持久化的日志保存与回放机制。每一个业务数据的写入操作（PUT DELETE）执行前，都会记账在WAL中。
如果出现HBase服务器宕机，则可以从WAL中回放执行之前没有完成的操作。
从线程模型、消息机制的层面上，解决这些问题：
1. 由于多个HBase客户端可以对某一台HBase Region Server发起并发的业务数据写入请求，因此WAL也要支持并发的多线程日志写入。——确保日志写入的线程安全、高并发。
2. 对于单个HBase客户端，它在WAL中的日志顺序，应该与这个客户端发起的业务数据写入请求的顺序一致。
（对于以上两点要求，大家很容易想到，用一个队列就搞定了。见下文的架构图。）
3. 为了保证高可靠，日志不仅要写入文件系统的内存缓存，而且应该尽快、强制刷到磁盘上（即WAL的Sync操作）。但是Sync太频繁，性能会变差。所以：
(1) Sync应当在多个后台线程中异步执行
(2) 频繁的多个Sync，可以合并为一次Sync——适当放松对可靠性的要求，提高性能。
WAL日志消费线程
WAL机制中，只有一个WAL日志消费线程，从队列中获取Append和Sync操作。这样一个多生产者，单消费者的模式，决定了WAL日志并发写入时日志的全局唯一顺序。
1. 对于获取到的Append操作，直接调用Hadoop Sequence File Writer将这个Append操作（包括元数据和row key, family, qualifier, timestamp, value等业务数据）写入文件
因此WAL日志文件使用的是Hadoop Sequence文件格式。当然，它也可以替换成其他存储格式，如Avro。
Hadoop Sequence文件格式不再这里累述，其主要特点是：
(1) 二进制格式。row key, family, qualifier, timestamp, value等HBase byte[]数据，都原封不动地顺序写入文件。
(2) Sequence文件中，每隔若干行，会插入一个16字节的魔数作为分隔符。这样如果文件损坏，导致某一行残缺不全，可以通过这个魔数分隔符跳过这一行，继续读取下一个完整的行。
(3) 支持压缩。可以按行压缩。也可以按块压缩（将多行打成一个块）
Hbase容错处理
WAL记载了每一个RegionServer对应的HLog。RegionServer1或者RegionServer1上某一个regiong挂掉了，都会迁移到其它的机器上处理，重新操作，进行恢复。
当RegionServer意外终止的时候，Master会通过Zookeeper感知到，Master首先会处理遗留下来的HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应的Region目录下，然后再将实效的Region重新分配，领取到这些Regio你的RegionMaster发现有历史的HLog需要处理，因此会Replay HLog的数据到Memstore之中，然后flush数据到StoreFiles，完成数据的恢复。
还了解过哪些大数据组件？Kafka组件。
Kafka是干啥的？消息队列。
引导至项目中消息队列的使用，Redis的pub/sub机制
Redis常见的数据结构以及作用。
详细讲下Bitmap
Redis和MemCache的区别？持久化机制。
讲下Redis哨兵模式。
八股结束。
详细讲一下简历的两个项目。项目的业务背景。自己在团队中的定位，负责的模块，遇到了什么问题，怎么解决的，这几个维度讲解。
六级是否过？
是否实习过？
写博客的习惯很好，继续保持！谢谢，整个秋招唯一注意到这点的面试官。solute!
二面 10-12 10:00 牛客 1v1 综合面试 1h Hr面
常规hr面试问题。
泡池子排序，今年海康池子深。是否能过听天由命，苏研推进至体检环节。
