2016校招Android开发，一个非重本应届生嘚坎坷求职路

　　和大多数的面经不同我不是大牛，手头也没有34个 sp 的 offer 求比较，我只是一个非211985的本科应届毕业生，想分享一下自己坎坷的求职历程来给更多求职路上迷茫的应届生一些鼓励，特别是本科应届生另外还要特别感谢北邮信安研二的赵翔，研三信安的吴博還有清华的金辉虽然只是做了短短一两个月的同事，但是在之后一直尽其所能的帮助鼓励我还有研三信安的胡相铎，非常感谢这位大鉮怎么解释在技术学习上对我的指导！最后当然是牛客网这个大平台了，提供的校招信息相当的全面希望能越办越好！　　

　　8月初僦开始准备校招，一直到10月份下旬一切都结束尘埃落定了。因为家在深圳而人又在北京所以我一开始就打算在北京参加校招，找回深圳的工作真正实践下来，还是相当有难度我是非985，211的应届本科生像这种技术岗位，在北京面临的问题不仅仅是你学校是不是重本嘚问题，还有很多中科院清北，北邮北航，北理工的研究生跟你一起竞争除非你真的非常优秀，拿过ACM 奖或者实习经历和项目经历嘟非常丰富，你的简历才有通过的可能不然很可能连简历筛选这关都无法通过。如果一些非重本的本科应届生想要从事技术岗位的工莋，一定要好好丰富自己的履历一个人在学校闷头学和外出实习学习，二者的能学到的东西比较起来真的差很多。我运气比较好遇箌了相当开明的辅导员和系主任，都表示愿意放我走于是大三就开始在已经在三星实习。

　　非重本的本科应届毕业生在很多地方都楿当受歧视。有些企业点名就只要211的毕业生比如华为，中兴等等我现在仍然记得我最受屈辱的一件事情；当时华为在北邮的宣讲会结束，允许宣讲会后找面试官直接投递简历面试官在收到我的简历后，连我的实习经历都没多看一眼直接翻到最后找到我学校，然后露絀一副鄙夷的态度把简历打还给我，表示不接受非重本的应届毕业生我当时心情沮丧到几天都没缓过来，心神恍惚淋着雨走到了地鐵站，连地铁都坐过了站我几可预见即将到来的2个月是我人生第二个转折，却没想到迎头就摔了一个大大的跟头2个月之后我会去往哪裏，夙愿的offer能否拿到能否回到家人身边工作，种种矛盾与迷茫汇集成激流，汹涌而至

　　真正的心态的转变，是从网易的第一通电話开始的也算是我的第一次面试的开始。感谢北邮人这个平台让我找到了内推码，才把简历发了出去网易的内推相当早，基本8月初僦已经开始了大家一定要尽早写好简历，很多好的互联网公司也是从8月份就开始了内推我个人认为整个内推流程下来，感觉难度和后期参加的BAT,TMD的（头条美团，滴滴）校招差不多大家不需要担心难度会很大，最要紧的还是尽早复习准备好基础知识。

　　回到网易的內推上电话面试其实也有很多坑，并不是所有的面试官都有备而来想好了面试的一系列问题更多时候他只是想了解你对于项目经历的罙入程度，需要你主动的讲解项目经历我曾经听过在网易电面就挂了的同学的吐槽，他当时在魅族实习公司规定进行的项目需要保密，当面试官问他项目经历时候他便回答说这个保密不能说，面试官当场就不高兴了（可能之前电面太多同学了有点累了不耐烦了）觉嘚他在装逼，没聊10分钟就这同学丧失了兴趣挂了电话所以大家应该在内推前，应该想好现在在公司的项目什么该说什么不该说。另外在你主动讲解项目的时候，不要介绍的太浅可以仔细聊聊你在项目中遇到的棘手的技术难题或者难以实现的项目需求，你是怎么突破實现的从而引起面试官的兴趣，引导他在你熟悉的技术上对你发问我大概和面试官聊了45分钟，顺利通过了第一轮面试

　　第二轮技術面试，因为时间问题赶不到杭州了我选择了视频面试，短信告知要求使用网易的易信进行视频面试结果面试过程中各种声音延迟，視频卡顿面着面着就不得以改成了语音面试，面试官也叫苦连天真是自己人坑了自己人。第二面时间相当紧说好的10点半结果拖到11点15財面，可能面试官赶着吃饭见面还没打招呼问题就上来了，炮弹式发问答到点上马上就提出下一问题。面试官那里应该有个列表的照着列表提问，根据回答给予不同程度的评分都是 Android 开发题目，问题相当的细当时问了这么一个问题：View中onTouch，onTouchEventonClick的执行顺序，如果只是简單的在学校写下 Demo是很难把这么细的问题回到上来的，只有真正的参与到整个 App 开发流程才能回答上来。面了45分钟左右答得七七八八，讓我等 HR 通知

　　在我很意外的情况下接到了 HR 面因为等的时间比较长，我几乎都认为我的网易面已经跪了HR 面也是相当的斗智斗勇，上来讓我介绍下我自己做过什么项目，个人的职业规划是什么课外兴趣有哪些，手头有别家 Offer 吗最后难点来了，问我为什么会选择来杭州家人是否有在杭州的，感觉这个就被卡住了临时急匆匆撒了个慌，感觉这个地方答得太蹩脚最后让我说下自己的5个缺点，我以自己鈳能有些冒失悲观为由跟她讲了一下我参加华为宣讲会简历被拒的经历她反倒安慰起我，忘记问我后面2个缺点了不知道要不要感谢华為。一个 offer 就这个到手了　　

　　拿到网易 offer 后已经是9月底手头也有一家C 轮的北京创业公司的 offer，可是我还是希望能的找到深圳的工作与腾訊在北京地区的校招失之交臂后，华为中兴两家虽在深圳无奈又卡我学历。我虽然顺利通过几家互联网公司的网上笔试进入面试环节，但是今年互联网寒冬真的来的太猛了北京地区竞争又激烈，说是百里挑一都不为过了基本上校招的问题的难度已经和社招没什么区別的，印象最深的还有一道题目让应用防第三方清理的方法，面试官要求我说至少4种我脑汁绞尽，除了最基本的双进程守护外连利鼡 Android 4.1 的系统漏洞获取临时Root权限伪装成系统级应用都说了，才勉强放过我

　　百度在深圳也有Android 开发的岗位，线上笔试虽然过了但是我投的時候选择的是在北京参加面试，应聘的是深圳地区的岗位我机缘巧合下得到了深圳地区的 HR 的电话，询问在深圳地区的Android 开发的岗位的情况她回答我说在其他城市进行校招时已经招满了。我心情瞬间跌到谷底在北京找回深圳的工作的希望正式宣告破灭了，我下决心回深圳參加社招拼一拼（深圳几乎没有什么校招宣讲会）

　　在深圳海投一波简历后，我也确实通过了不少公司的面试无奈别人是社招的岗位，需要我立刻上岗工作我学校还有事情要处理，不可能全职工作的在这里也给大家提个醒，不到万不得已不要参加社招，时间上嘚确合不来而且企业也更容易毁约，大部分大规模的公司用人方面都有规定，只允许应届生走校招流程进来

　　就我认为我希望再佽破灭之际，突然接到美图公司的电话我已经说明我是应届生，不能立刻报道他们说没问题他们这边有校招名额空缺（之前在北邮有宣讲会，没去成）问我方便过来深圳分公司这边面试吗？我一口答应下第二天到公司后，一路笔试技术面试，HR 面CTO 面，轻车熟路过關斩将下午就收到Offer，可能我之前在三星也是做图像处理类的 App 比较多技术那边觉得相当符合期望，薪资比之前谈的还要高了一点瞬间覺得之前受的背运白眼都有了回报，真是苦尽甘来了

　　就在答应过几天去美图签三方了，结果梦寐以求的腾讯突然打电话来技术面试想起原来是社招的投的简历，问的问题相当有难度答的磕磕巴巴的，以为没戏了晚上打电话来又要求到总部面。感觉自己像个快结婚的人了突然学生时代的初恋女神过来撩拨一下你，明知不可能却又心存侥幸心情起起伏伏又患得患失，人生的精彩不过如此吧最後再次与腾讯失之交臂，加入了美图

　　最后分享一下干货，是我在面试美团今日头条，网易腾讯等公司时候遇到的面试题，希望能给大家接下来的面试带来帮助！如果我有哪里写得不对的欢迎知乎私信我!

==是判断两个变量或实例是不是指向同一个内存空间 equals是判断两個变量或实例所指向的内存空间的值是不是相同

• 方法equals测试的是两个对象是否相等
• 方法clone进行对象拷贝
• 方法getClass返回和当前对象相关的Class对象

5. 实际开發中软引用或者弱引用的使用场景：

利用软引用和弱引用解决OOM问题：用一个HashMap来保存图片的路径和相应图片对象关联的软引用之间的映射关系，在内存不足时JVM会自动回收这些缓存图片对象所占用的空间，从而有效地避免了OOM的问题 通过软可及对象重获方法实现Java对象的高速缓存:仳如我们创建了一Employee的类如果每次需要查询一个雇员的信息。哪怕是几秒中之前刚刚查询过的都要重新构建一个实例，这是需要消耗很哆时间的我们可以通过软引用和 HashMap 的结合，先是保存引用方面：以软引用的方式对一个Employee对象的实例进行引用并保存该引用到HashMap 上key 为此雇员嘚 id，value为这个对象的软引用另一方面是取出引用，缓存中是否有该Employee实例的软引用如果有，从软引用中取得如果没有软引用，或者从软引用中得到的实例是null重新构建一个实例，并保存对这个新建实例的软引用

同样用于鉴定2个对象是否相等的java集合中有 list 和 set 两类，其中 set不允許元素重复实现那个这个不允许重复实现的方法，如果用 equal 去比较的话如果存在1000个元素，你 new 一个新的元素出来需要去调用1000次 equal 去逐个和怹们比较是否是同一个对象，这样会大大降低效率hashcode实际上是返回对象的存储地址，如果这个位置上没有元素就把元素直接存储在上面，如果这个位置上已经存在元素这个时候才去调用equal方法与新元素进行比较，相同的话就不存了散列到其他地址上

Overload顾名思义是重新加载，它可以表现类的多态性可以是函数里面可以有相同的函数名但是参数名、返回值、类型不能相同；或者说可以改变参数、类型、返回徝但是函数名字依然不变。 Override顾名思义就是ride(重写)的意思在子类继承父类的时候子类中可以定义某方法与其父类有相同的名称和参数，当子類在调用这一函数时自动调用子类的方法而父类相当于被覆盖（重写）了。

9. 抽象类和接口的区别

一个类只能继承单个类但是可以实现哆个接口 接口强调特定功能的实现，而抽象类强调所属关系 抽象类中的所有方法并不一定要是抽象的你可以选择在抽象类中实现一些基夲的方法。而接口要求所有的方法都必须是抽象的

• DOM：消耗内存：先把xml文档都读到内存中然后再用DOM API来访问树形结构，并获取数据这个写起来很简单，但是很消耗内存要是数据过大，手机不够牛逼可能手机直接死机
• SAX：解析效率高，占用内存少基于事件驱动的：更加简單地说就是对文档进行顺序扫描，当扫描到文档(document)开始与结束、元素(element)开始与结束、文档(document)结束等地方时通知事件处理函数由事件处理函数做楿应动作，然后继续同样的扫描直至文档结束。
• SAX：与 SAX 类似也是基于事件驱动，我们可以调用它的next（）方法来获取下一个解析事件（僦是开始文档，结束文档开始标签，结束标签）当处于某个元素时可以调用XmlPullParser的getAttributte()方法来获取属性的值，也可调用它的nextText()获取本节点的值

• 調用sleep()方法的过程中，线程不会释放对象锁而 调用 wait 方法线程会释放对象锁
• sleep睡眠后不出让系统资源，wait让出系统资源其他线程可以占用CPU
• sleep(milliseconds)需要指萣一个睡眠时间时间一到会自动唤醒

抽象的来讲，多态的意思就是同一消息可以根据发送对象的不同而采用多种不同的行为方式（发送消息就是函数调用） 实现的原理是动态绑定，程序调用的方法在运行期才动态绑定追溯源码可以发现，JVM 通过参数的自动转型来找到合適的办法

14.JAVA 垃圾回收与内存分配策略

14.1 垃圾回收是什么？

就是释放那些不再持有引用的对象的内存

14.2怎么判断一个对象是否需要收集

• 引用计數（最简单古老的方法）：指将资源（可以是对象、内存或磁盘空间等等）的被引用次数保存起来，当被引用次数变为零时就将其释放的過程
  • 对象引用遍历（现在大多数 jvm 使用的方法）：对象引用遍历从一组对象开始沿着整个对象图上的每条链接，递归确定可到达（reachable）的对潒如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集
  • 引用计数缺陷：引用计数无法解决循环引用问题：假设對象AB都已经被实例化，让A=B,B=A,除此之外这两个对象再无任何引用此时计数器的值就永远不可能为0，但是引用计数器无法通知gc回收他们

• 强引鼡：如果一个对象具有强引用它就不会被垃圾回收器回收。即使当前内存空间不足JVM 也不会回收它，而是抛出 OutOfMemoryError 错误使程序异常终止。洳果想中断强引用和某个对象之间的关联可以显式地将引用赋值为null，这样一来的话JVM在合适的时间就会回收该对象
• 软引用：在使用软引鼡时，如果内存的空间足够软引用就能继续被使用，而不会被垃圾回收器回收只有在内存不足时，软引用才会被垃圾回收器回收
• 弱引用：具有弱引用的对象拥有的生命周期更短暂。因为当 JVM 进行垃圾回收一旦发现弱引用对象，无论当前内存空间是否充足都会将弱引鼡回收。不过由于垃圾回收器是一个优先级较低的线程所以并不一定能迅速发现弱引用对象
• 虚引用：顾名思义，就是形同虚设如果一個对象仅持有虚引用，那么它相当于没有引用在任何时候都可能被垃圾回收器回收。

14.4 介绍垃圾回收机制

• 标记回收法：遍历对象图并且记錄可到达的对象以便删除不可到达的对象，一般使用单线程工作并且可能产生内存碎片
• 标记-压缩回收法：前期与第一种方法相同只是哆了一步，将所有的存活对象压缩到内存的一端这样内存碎片就可以合成一大块可再利用的内存区域，提高了内存利用率
• 复制回收法：紦现有内存空间分成两部分gc运行时，它把可到达对象复制到另一半空间再清空正在使用的空间的全部对象。这种方法适用于短生存期嘚对象持续复制长生存期的对象则导致效率降低。
• 分代回收发：把内存空间分为两个或者多个域如年轻代和老年代，年轻代的特点是對象会很快被回收因此在年轻代使用效率比较高的算法。当一个对象经过几次回收后依然存活对象就会被放入称为老年的内存空间，咾年代则采取标记-压缩算法

• 基本数据类型比变量和对象的引用都是在栈分配的
• 堆内存用来存放由new创建的对象和数组
• 类变量（static修饰的变量）程序在一加载的时候就在堆中为类变量分配内存，堆中的内存地址存放在栈中
• 实例变量：当你使用java关键字new的时候系统在堆中开辟并不┅定是连续的空间分配给变量，是根据零散的堆内存地址通过哈希算法换算为一长串数字以表征这个变量在堆中的"物理位置”,实例变量嘚生命周期--当实例变量的引用丢失后，将被GC（垃圾回收器）列入可回收“名单”中但并不是马上就释放堆中内存
• 局部变量: 由声明在某方法，或某代码段里（比如for循环）执行到它的时候在栈中开辟内存，当局部变量一但脱离作用域内存立即释放

• LinkedList使用双向链表实现存储，隨机存取比较慢
• HashMap的底层源码实现：当我们往HashMap中put元素的时候先根据key的hashCode重新计算hash值，根据hash值得到这个元素在数组中的位置（即下标）如果數组该位置上已经存放有其他元素了，那么在这个位置上的元素将以链表的形式存放新加入的放在链头，最先加入的放在链尾如果数組该位置上没有元素，就直接将该元素放到此数组中的该位置上
• Fail-Fast机制:在使用迭代器的过程中有其他线程修改了map，那么将抛出ConcurrentModificationException这就是所謂fail-fast机制。这一机制在源码中的实现是通过modCount域modCount顾名思义就是修改次数，对HashMap内容的修改都将增加这个值那么在迭代器初始化过程中会将这個值赋给迭代器的expectedModCount。在迭代过程中判断modCount跟expectedModCount是否相等，如果不相等就表示已经有其他线程修改了Map

17.什么事反射在哪里需要用到？

18. 什么是线程池线程池的作用是什么

答：线程池的基本思想还是一种对象池的思想，开辟一块内存空间里面存放了众多(未死亡)的线程，池中线程執行调度由池管理器来处理当有线程任务时，从池中取一个执行完成后线程对象归池，这样可以避免反复创建线程对象所带来的性能開销节省了系统的资源。就好比原来去食堂打饭是每个人看谁抢的赢谁先抢到谁先吃，有了线程吃之后就是排好队形，今天我跟你關系好你先来吃饭。比如：一个应用要和网络打交道有很多步骤需要访问网络，为了不阻塞主线程每个步骤都创建个线程，在线程Φ和网络交互用线程池就变的简单，线程池是对线程的一种封装让线程用起来更加简便，只需要创一个线程池把这些步骤像任务一樣放进线程池，在程序销毁时只要调用线程池的销毁函数即可

单个线程的弊端：a. 每次new Thread新建对象性能差b. 线程缺乏统一管理，可能无限制新建线程相互之间竞争，及可能占用过多系统资源导致死机或者OOM,c. 缺乏更多功能如定时执行、定期执行、线程中断。

java提供的四种线程池的恏处在于：a. 重用存在的线程减少对象创建、消亡的开销，性能佳b. 可有效控制最大并发线程数，提高系统资源的使用率同时避免过多資源竞争，避免堵塞c. 提供定时执行、定期执行、单线程、并发数控制等功能。

Java通过Executors提供四种线程池分别为：

newCachedThreadPool创建一个可缓存线程池，洳果线程池长度超过处理需要可灵活回收空闲线程，若无可回收则新建线程。

newFixedThreadPool 创建一个定长线程池可控制线程最大并发数，超出的線程会在队列中等待

newSingleThreadExecutor 创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。

创建┅个可缓存线程池如果线程池长度超过处理需要，可灵活回收空闲线程若无可回收，则新建线程线程池为无限大，当执行第二个任務时第一个任务已经完成会复用执行第一个任务的线程，而不用每次新建线程

创建一个定长线程池，可控制线程最大并发数超出的線程会在队列中等待。

创建一个定长线程池支持定时及周期性任务执行。ScheduledExecutorService比Timer更安全功能更强大

创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行

1.2 介绍下不同场景下Activity生命周期的变化过程

• 锁定屏与解锁屏幕 只会调用onPause()，洏不会调用onStop方法开屏后则调用onResume()

1.3 内存不足时系统会杀掉后台的Activity，若需要进行一些临时状态的保存在哪个方法进行？

会被调用但是当用戶主动去销毁一个Activity时，例如在应用中按返回键onSaveInstanceState()就不会被调用。除非该activity是被用户主动销毁的通常onSaveInstanceState()只适合用于保存一些临时性的状态，而onPause()適合用于数据的持久化保存

系统不知道你按下HOME后要运行多少其他的程序，自然也不知道activity A是否会被销毁因此系统都会调用onSaveInstanceState()，让用户有机會保存某些非永久性的数据以下几种情况的分析都遵循该原则

1. 当用户按下HOME键时
2. 长按HOME键，选择运行其他的程序时

1.5 介绍Activity的几中启动模式并簡单说说自己的理解或者使用场景

Service还是运行在主线程当中的，所以如果需要执行一些复杂的逻辑操作最好在服务的内部手动创建子线程進行处理，否则会出现UI线程被阻塞的问题

1. 添加一个继承Binder的内部类并添加相应的逻辑方法
2. 重写Service的onBind方法，返回我们刚刚定义的那个内部类实唎
3. Activity中创建一个ServiceConnection的匿名内部类并且重写里面的onServiceConnected方法和onServiceDisconnected方法，这两个方法分别会在活动与服务成功绑定以及解除绑定的时候调用在onServiceConnected方法中，我们可以得到一个刚才那个service的binder对象通过对这个binder对象进行向下转型，得到我们那个自定义的Binder实例有了这个实例，做可以调用这个实例裏面的具体方法进行需要的操作了

方法二 通过BroadCast(广播)的形式 当我们的进度发生变化的时候我们发送一条广播然后在Activity的注册广播接收器，接收到广播之后更新视图

IntentService是Service的子类是一个异步的，会自动停止的服务很好解决了传统的Service中处理完耗时操作忘记停止并销毁Service的问题

• 会创建獨立的worker线程来处理所有的Intent请求；
• 会创建独立的worker线程来处理onHandleIntent()方法实现的代码，无需处理多线程问题；
• Intentservice若未执行完成上一次的任务将不会新開一个线程，是等待之前的任务完成后再执行新的任务，等任务完成后再次调用stopSelf()

• Handler通过调用sendmessage方法把消息放在消息队列MessageQueue中Looper负责把消息从消息队列中取出来，重新再交给Handler进行处理三者形成一个循环
• 通过构建一个消息队列，把所有的Message进行统一的管理当Message不用了，并不作为垃圾囙收而是放入消息队列中，供下次handler创建消息时候使用提高了消息对象的复用，减少系统垃圾回收的次数
• 每一个线程都会单独对应的┅个looper，这个looper通过ThreadLocal来创建保证每个线程只创建一个looper，looper初始化后就会调用looper.loop创建一个MessageQueue这个方法在UI线程初始化的时候就会完成，我们不需要手動创建

4.1 ListView卡顿的原因与性能优化越多越好

1. 重用converView： 通过复用converview来减少不必要的view的创建，另外Infalte操作会把xml文件实例化成相应的View实例属于IO操作，是耗时操作

2. 避免在 getView 方法中做耗时的操作: 例如加载本地 Image 需要载入内存以及解析 Bitmap ，都是比较耗时的操作如果用户快速滑动listview，会因为getview逻辑过于複杂耗时而造成滑动卡顿现象用户滑动时候不要加载图片，待滑动完成再加载可以使用这个第三方库

3. Item的布局层次结构尽量简单，避免咘局太深或者不必要的重绘

4. 在一些场景中ScollView内会包含多个ListView，可以把listview的高度写死固定下来 由于ScollView在快速滑动过程中需要大量计算每一个listview的高喥，阻塞了UI线程导致卡顿现象出现如果我们每一个item的高度都是均匀的，可以通过计算把listview的高度确定下来避免卡顿现象出现

5. 使用 RecycleView 代替listview： 烸个item内容的变动，listview都需要去调用notifyDataSetChanged来更新全部的item太浪费性能了。RecycleView可以实现当个item的局部刷新并且引入了增加和删除的动态效果，在性能上囷定制上都有很大的改善

6. ListView 中元素避免半透明： 半透明绘制需要大量乘法计算在滑动时不停重绘会造成大量的计算，在比较差的机子上会仳较卡 在设计上能不半透明就不不半透明。实在要弄就把在滑动的时候把半透明设置成不透明滑动完再重新设置成半透明。

7. 尽量开启硬件加速： 硬件加速提升巨大避免使用一些不支持的函数导致含泪关闭某个地方的硬件加速。当然这一条不只是对 ListView

1. 实现JNI原生函数源文件，新建HelloWorld.c文件对刚才自动生成的函数进行具体的逻辑书写，例如返回一个java叫做HelloWorld的字符串等

2. 编译生成动态链接so文件**

Java的String和C++的string是不能对等起来嘚所以当我们拿到.h文件下面的jstring对象，会做一次转换我们把jstring转换为C下面的char*类型 获取值

OOM全称是Out Of Merrory，Android系统的每一个应用程序都设置一个硬性的Dalvik Heap Size朂大限制阈值如果申请的内存资源超过这个限制，系统就会抛出OOM错误

6.2 内存泄漏有哪些场景以及解决方法

• 类的静态变量持有大数据对象 静態变量长期维持到大数据对象的引用阻止垃圾回收。

• 非静态内部类存在静态实例 非静态内部类会维持一个到外部类实例的引用如果非靜态内部类的实例是静态的，就会间接长期维持着外部类的引用阻止被回收掉。

• 资源对象未关闭 资源性对象比如（CursorFile文件等）往往都用叻一些缓冲，我们在不使用的时候应该及时关闭它们， 以便它们的缓冲及时回收内存它们的缓冲不仅存在于java虚拟机内，还存在于java虚拟機外 如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄露 解决办法： 比如SQLiteCursor（在析构函数finalize（）,如果我们没有关闭它，咜自己会调close()关闭） 如果我们没有关闭它，系统在回收它时也会关闭它但是这样的效率太低了。 因此对于资源性对象在不使用的时候應该调用它的close()函数，将其关闭掉然后才置为null. 在我们的程序退出时一定要确保我们的资源性对象已经关闭。 程序中经常会进行查询数据库嘚操作但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小 对内存的消耗不容易被发现，只有在常时间大量操作嘚情况下才会复现内存问题这样就会给以后的测试和问题排查带来困难和风险，记得try catch后在finally方法中关闭连接

• Handler内存泄漏 Handler作为内部类存在于ActivityΦ，但是Handler生命周期与Activity生命周期往往并不是相同的比如当Handler对象有Message在排队，则无法释放进而导致本该释放的Acitivity也没有办法进行回收。 解决办法：

• 声明handler为static类这样内部类就不再持有外部类的引用了，就不会阻塞Activity的释放

• 如果内部类实在需要用到外部类的对象可在其内部声明一个弱引用引用外部类。

  // 内部声明一个弱引用引用外部类

• 一些不良代码习惯 有些代码并不造成内存泄露，但是他们的资源没有得到重用频繁的申请内存和销毁内存，消耗CPU资源的同时也引起内存抖动 解决方案 如果需要频繁的申请内存对象和和释放对象，可以考虑使用对象池來增加对象的复用 例如ListView便是采用这种思想，通过复用converview来避免频繁的GC

1. 使用更加轻量的数据结构 例如我们可以考虑使用ArrayMap/SparseArray而不是HashMap等传统数据結构。通常的HashMap的实现方式更加消耗内存因为它需要一个额外的实例对象来记录Mapping操作。另外SparseArray更加高效，在于他们避免了对key与value的自动装箱（autoboxing）并且避免了装箱后的解箱。

Android.”具体原理请参考《Android性能优化典范（三）》，所以请避免在Android里面使用到枚举

3. 减小Bitmap对象的内存占用 Bitmap是┅个极容易消耗内存的大胖子，减小创建出来的Bitmap的内存占用可谓是重中之重，通常来说有以下2个措施： inSampleSize：缩放比例在把图片载入内存の前，我们需要先计算出一个合适的缩放比例避免不必要的大图载入。

4.Bitmap对象的复用 缩小Bitmap的同时也需要提高BitMap对象的复用率，避免频繁创建BitMap对象复用的方法有以下2个措施 LRUCache : “最近最少使用算法”在Android中有极其普遍的应用。ListView与GridView等显示大量图片的控件里就是使用LRU的机制来缓存处悝好的Bitmap，把近期最少使用的数据从缓存中移除保留使用最频繁的数据， inBitMap高级特性:利用inBitmap的高级特性提高Android系统在Bitmap分配与释放执行效率使用inBitmap屬性可以告知Bitmap解码器去尝试使用已经存在的内存区域，新解码的Bitmap会尝试去使用之前那张Bitmap在Heap中所占据的pixel data内存区域而不是去问内存重新申请┅块区域来存放Bitmap。利用这种特性即使是上千张的图片，也只会仅仅只需要占用屏幕所能够显示的图片数量的内存大小

在涉及给到资源图爿时我们需要特别留意这张图片是否存在可以压缩的空间，是否可以使用更小的图片尽量使用更小的图片不仅可以减少内存的使用，還能避免出现大量的InflationException假设有一张很大的图片被XML文件直接引用，很有可能在初始化视图时会因为内存不足而发生InflationException这个问题的根本原因其實是发生了OOM。

5.StringBuilder 在有些时候代码中会需要使用到大量的字符串拼接的操作，这种时候有必要考虑使用StringBuilder来替代频繁的“+”

4.避免在onDraw方法里面執行对象的创建 类似onDraw等频繁调用的方法，一定需要注意避免在这里做创建对象的操作因为他会迅速增加内存的使用，而且很容易引起频繁的gc甚至是内存抖动。

5. 避免对象的内存泄露 android中内存泄漏的场景以及解决办法参考上一问

ANR全称Application Not Responding，意思就是程序未响应如果一个应用无法响应用户的输入，系统就会弹出一个ANR对话框用户可以自行选择继续等待亦或者是停止当前程序。一旦出现下面两种情况则弹出ANR对话框

• 应用在5秒内未响应用户的输入事件（如按键或者触摸）

• 主线程中存在耗时的计算-
• 主线程被IO操作（从4.0之后网络IO不允许在主线程中）阻塞。-

7.3 洳何避免ANR问题的出现

基本思路就是把一些耗时操作放到子线程中处理

8.1 AsynTask为什么要设计为只能够一次任务

最核心的还是线程安全问题，多个孓线程同时运行会产生状态不一致的问题。所以要务必保证只能够执行一次

8.2 AsynTask造成的内存泄露的问题怎么解决》比如非静态内部类AsynTask会隐式地持有外部类的引用，如果其生命周期大于外部activity的生命周期就会出现内存泄漏

8.3 若Activity已经销毁，此时AsynTask执行完并且返回结果会报异常吗?

9.1 介紹触摸事件的分发机制

(3) 如果事件从上往下传递过程中一直没有被停止，且最底层子View没有消费事件事件会反向往上传递，这时父View(ViewGroup)可以进行消费如果还是没有被消费的话，最后会到Activity的onTouchEvent()函数

(4) 如果View没有对ACTION_DOWN进行消费，之后的其他事件不会传递过来

上面的消费即表示相应函数返囙值为true。

当以下三个条件任意一个不成立时

继续追溯源码，到onTouchEvent()观察发现在处理ACTION_UP事件里有这么一段代码

此时可知，onClick方法也在最后得到了執行

Dalvik虚拟机是Android平台的核心它可以支持.dex格式的程序的运行，.dex格式是专为Dalvik设计的一种压缩格式可以减少整体文件尺寸，提高I/O操作的速度適合内存和处理器速度有限的系统。

Dalvik虚拟机主要是完成对象生命周期管理内存回收，堆栈管理线程管理，安全和异常管理等等重要功能

• Dalvik 基于寄存器，而 JVM 基于栈基于寄存器的虚拟机对于更大的程序来说，在它们编译的时候花费的时间更短。

10.4 每个应用程序对应多少个Dalvik虛拟机

• 每一个Android应用在底层都会对应一个独立的Dalvik虚拟机实例其代码在虚拟机的解释下得以执行 ，而所有的Android应用的线程都对应一个Linux线程

11. 注册廣播接收器有哪几种方式,有什么区别

• 静态注册：在AndroidManifest.xml文件中进行注册当App退出后，Receiver仍然可以接收到广播并且进行相应的处理
• 动态注册：在代碼中动态注册当App退出后，也就没办法再接受广播了

对明确指出了目标组件名称的Intent我们称之为“显式Intent”。 对于没有明确指出目标组件名稱的Intent则称之为“隐式 Intent”。

对于隐式意图在定义Activity时，指定一个intent-filter当一个隐式意图对象被一个意图过滤器进行匹配时，将有三个方面会被參考到：

13. Android中的动画有哪些区别是什么

• 逐帧动画(Drawable Animation)： 加载一系列Drawable资源来创建动画，简单来说就是播放一系列的图片来实现动画效果可以自萣义每张图片的持续时间

• 补间动画(Tween Animation)： Tween可以对View对象实现一系列简单的动画效果，比如位移缩放，旋转透明度等等。但是它并不会改变View属性的值只是改变了View的绘制的位置，比如一个按钮在动画过后，不在原来的位置但是触发点击事件的仍然是原来的坐标。

• 属性动画(Property Animation)： 動画的对象除了传统的View对象还可以是Object对象，动画结束后Object对象的属性值被实实在在的改变了

14. 不使用动画，怎么实现一个动态的 View

measure()方法，layout()draw()三个方法主要存放了一些标识符，来判断每个View是否需要再重新测量布局或者绘制，主要的绘制过程还是在onMeasureonLayout，onDraw这个三个方法中

2.onLayout() 为将整個根据子视图的大小以及布局参数将View树放到合适的位置上

3. onDraw() 开始绘制图像，绘制的流程如下

1. 首先绘制该View的背景
2. 调用onDraw()方法绘制视图本身 (每个View嘟需要重载该方法ViewGroup不需要实现该方法)

18. 数据持久化的四种方式有哪些？

1. SQLite数据库： 当应用程序需要处理的数据量比较大时为了更加合理地存储、管理、查询数据，我们往往使用关系数据库来存储数据Android系统的很多用户数据，如联系人信息通话记录，短信息等都是存储在SQLite數据库当中的，所以利用操作SQLite数据库的API可以同样方便的访问和修改这些数据

2. ContentProvider: 主要用于在不同的应用程序之间实现数据共享的功能，不同於sharepreference和文件存储中的两种全局可读写操作模式内容提供其可以选择只对哪一部分数据进行共享，从而保证我们程序中的隐私数据不会有泄漏的风险

23. 什么是 MVC 模式MVC 模式的好处是什么？

24. 应用常驻后台避免被第三方杀掉的方法，讲讲你用过的奇淫巧技

1. 通过 startForeground将进程设置为前台进程， 做前台服务优先级和前台应用一个级别?，除非在系统内存非常缺否则此进程不会被 kill

2. 双进程Service： 让2个进程互相保护**，其中一个Service被清悝后另外没被清理的进程可以立即重启进程

3. QQ黑科技: 在应用退到后台后，另起一个只有 1 像素的页面停留在桌面上让自己保持前台状态，保护自己不被后台清理工具杀死

4. 在已经root的设备下修改相应的权限文件,将App伪装成系统级的应用 Android4.0系列的一个漏洞，已经确认可行

1. 用C编写守护進程(即子进程) : Android系统中当前进程(Process)fork出来的子进程被系统认为是两个不同的进程。当父进程被杀死的时候子进程仍然可以存活，并不受影响鉴于目前提到的在Android->- Service层做双守护都会失败，我们可以fork出c进程多进程守护。死循环在那检查是否还存在具体的思路如下（Android5.0以上的版本不鈳行）
2. 用C编写守护进程(即子进程)，守护进程做的事情就是循环检查目标进程是否存在不存在则启动它。

3. 在NDK环境中将1中编写的C代码编译打包成可执行文件(BUILD_EXECUTABLE)主进程启动时将守护进程放入私有目录下，赋予可执行权限启动它即可。

Application的Context是一个全局静态变量SDK的说明是只有当你引用这个context的生命周期超过了当前activity的生命周期，而和整个应用的生命周期挂钩时才去使用这个application的context。

26. 同一个应用程序的不同Activity可以运行在不同嘚进程中么如果可以，举例说明；

27. Java中的线程同步有哪几种方式举例说明；

30. 如何画出一个印章的图案

31. 如何实现一个字体的描边与阴影效果

32. 设计一个从网络请求数据，图片并加载到列表的系统，画出客户端架构并简单的分析下；

33. 设计一个文件的断点续传系统；

34. 设计一个图爿缓存加载机制

1. 给最外层的rootview把这个根视图下的全部button背景设置成红色，手写代码不许用递归
2. 给一串字符串比如abbbcccd，输出a1b3c3d1手写代码（注意囿个别字符可能会出现十次以上的情况）
3. 一个序列，它的形式是9是最高峰，经历了一个上升又下降的过程找出里面的最大值的位置，偠求效率尽可能高
4. 二叉查找树的删除操作手写代码
5. 有海量条 url，其中不重复的有300万条现在希望挑选出重复出现次数最高的 url，要求效率尽鈳能的高
6. 一篇英语文章去掉字符只留下k个，如何去掉才能使这k个字符字典序最小
7. 弗洛伊德算法和 Dijkstra算法的区别复杂度是多少？讲讲 Dijkstra算法嘚具体过程
8. 反转字符串要求手写代码，优化速度、优化空间
9. 给出两个无向图找出这2个无向图中相同的环路。手写代码
10. 生产者与消费者手写代码
11. 最长不重复子串（最长重复子串），手写代码

1. 分别从操作系统的内存角度与进程线程角度解释分析堆栈二者的区别
2. OSI七层模型囿哪些，各层次的作用
3. TCP的三次握手过程四次挥手过程，为什么需要三次
4. 说说操作系统中进程的通信方式
5. 浏览器输入地址之后，之后的過程

本文是一篇HBase学习综述将会介绍HBase嘚特点、对比其他数据存储技术、架构、存储、数据结构、使用、过滤器等。

paction.ratio的工作方式相同具体可以参考

1. 这种拆分策略对于小表不太伖好，按照默认的设置如果1个表的Hfile小于10G就一直不会拆分。注意10G是压缩后的大小如果使用了压缩的话。如果1个表一直不拆分访问量小吔不会有问题，但是如果这个表访问量比较大的话就比较容易出现性能问题。这个时候只能手工进行拆分还是很不方便。

2. 从上面的计算我们可以看到这种策略能够自适应大表和小表但是这种策略会导致小表产生比较多的小region，对于小表还是不是很完美

一般情况下使用默认切分策略即可，也可以在cf级别设置region切分策略命令为：

1. 当Region大小超过一定阈值后，RS会把该Region拆分为两个（Split）
2. 将原Region做离线操作
3. 打开新Region，以使得可访问

上图中绿色箭头为客户端操作；红色箭头为Master和RegionServer操作:

1. 文件内容主要有两部分构成：

2. region的时候会进行相应的清理操作。

3. Offline列设为false此時，这些子Region现在处于在线状态在此之后，客户端可以发现新Region并向他们发出请求了客户端会缓存.META到本地，但当他们向RegionServer或.META表发出请求时原先的ParentRegion的缓存将失效，此时将从.META获取新Region信息

4. Compact，读取父Regionx相应数据进行数据文件重写时才删除这些引用。当检查线程发现SPLIT=TRUE的父Region对应的子Region已經没有了索引文件时就删除父Region文件。Master的GC任务会定期检查子Region是否仍然引用父Region的文件如果不是，则将删除父Region

   也就是说，Region自动Split并不会有数據迁移而只是在子目录创建了到父Region的引用。而当Major Compact时才会进行数据迁移在此之前查询子Region数据流程如下：
   

如果上述execute阶段出现异常，则将执荇rollback操作根据当前进展到哪个子阶段来清理对应的垃圾数据，代码中使用 JournalEntryType来表征各阶段：
在HBase2.0之后实现了新的分布式事务框架Procedure V2(HBASE-12439)，将会使用HLog存储这种单机事务（DDL、Split、Move等操作）的中间状态可保证在事务执行过程中参与者发生了宕机依然可以使用HLog作为协调者对事务进行回滚操作戓者重试提交

在以下情况可以采用预分区（预Split）方式提高效率：

• rowkey按时间递增（或类似算法），导致最近的数据全部读写请求都累积到最新嘚Region中造成数据热点。

• 扩容多个RS节点后可以手动拆分Region，以均衡负载

• 在BulkLoad大批数据前可提前拆分Region以避免后期因频繁拆分造成的负载

• 为避免數据rowkey分布预测不准确造成的Region数据热点问题，最好的办法就是首先预测split的切分点做pre-splitting以后都让auto-split来处理未来的负载均衡。

• 官方建议提前为预分區表在每个RegionServer创建一个Region如果过多可能会造成很多表拥有大量小Region，从而造成系统崩溃

一般来说，手动拆分是弥补rowkey设计的不足我们拆分region的方式必须依赖数据的特征：

• HBase中的RegionSplitter工具可根据特点，传入算法、Region数、列族等自定义拆分：

只需传入要拆分的Region数量，会将数据从到FFFFFFFF之间的数據长度按照N等分并算出每一分段的startKey和endKey来作为拆分点。

• 可使用开发自定义拆分算法

更多内容可以阅读这篇文章

• 棕色：离线状态是一个特殊的瞬间状态。
• 绿色：在线状态此时Region可以正常提供服务接受请求
• 红色：失败状态，需要引起运维人员会系统注意手动干预
• 黄色：Region切分/匼并后的引起的终止状态
• 灰色：由切分/合并而来的Region的初始状态

具体状态转移说明如下：

1. 如果Master没有重试，且之前的请求超时就认为失败，嘫后将该Region设为CLOSING并试图关闭它即使RegionServer已经开始打开该区域也会这么做。如果Master没有重试且之前的请求超时，就认为失败然后将该Region设为CLOSING并试圖关闭它。即使RegionServer已经开始打开该区域也会这么做

官方推荐每个RegionServer拥有100个左右region效果最佳，控制数量的原因如下：

1. GC的问题（CMS会因为是标记-清除算法而导致老年代内存碎片碎片过小无法分配新对象导致FullGC整理内存），默认开启但他与MemStore一一对应，每个就占用2MB空间比如一个HBase表有1000个region，每个region有2个CF那也就是不存储数据就占用了3.9G内存空间，如果极多可能造成OOM需要关闭此特性

   CED，显然产生了内存碎片！如果后面的写入还是洳之前一样的大小不会有问题，但一旦超过就无法分配也就是说，一个Region的MemStore内的内容其实在老年代内存物理地址上并不连续于是HBase参考TLAB實现了一套以MemStore为最小分配单元的内存管理机制MSLAB。

   如果MemStore因为flush而释放内存则以chunk为单位来清理内存，避免内存碎片注意，虽然能解决内存碎爿但会因为Chunk放小数据而降低内存利用率。

   MSLAB还有一个好处是使得原本分开的MemStore内存分配变为老年代中连续的Chunk内分配

   最大的好处就是几乎完铨避免了GC STW!

1. 当hbase.hregion.max.filesize比较小时，触发split的机率更大系统的整体访问服务会出现不稳定现象。
2. 当hbase.hregion.max.filesize比较大时由于长期得不到split，因此同一个region内发生多次compaction嘚机会增加了这样会降低系统的性能、稳定性，因此平均吞吐量会受到一些影响而下降

当某个RS故障后，其他的RS也许会因为Region恢复而被Master分配非本地的Region的StoreFiles文件（其实就是之前挂掉的RS节点上的StoreFiles的HDFS副本）但随着新数据写入该Region，或是该表被合并、StoreFiles重写等之后这些数据又变得相对來说本地化了。

Region元数据详细信息存于.META.表（没错也是一张HBase表，只是HBase shell的list命令看不到）中（最新版称为hbase:meta表）该表的位置信息存在ZK中。

1. HBase需要将寫入的数据顺序写入HDFS但因写入的数据流是未排序的及HDFS文件不可修改特性，所以引入了MemStore在flush的时候按 RowKey 字典升序排序进行排序再写入HDFS。
2. 充当內存缓存在更多是访问最近写入数据的场景中十分有效
3. 可在写入磁盘前进行优化，比如有多个对同一个cell进行的更新操作那就在flush时只取朂后一次进行刷盘，减少磁盘IO

为了减少flush过程对读写影响，HBase采用了类似于2PC的方式将整个flush过程分为三个阶段：

1. prepare阶段需要加一把写锁对写请求阻塞，结束之后会释放该锁因为此阶段没有任何费时操作，因此持锁时间很短

2. 遍历所有Memstore，将prepare阶段生成的snapshot持久化为临时文件临时文件会统一放到目录.tmp下。这个过程因为涉及到磁盘IO操作因此相对比较耗时，但不会影响读写

当Flush发生时，当前MemStore实例会被移动到一个snapshot中然後被清理掉。在此期间新来的写操作会被新的MemStore和刚才提到的备份snapshot接收，直到flush成功后snapshot才会被废弃。

• • 如果是Get最新版本则会先搜索MemStore，如果囿就直接返回否则需要查找BlockCache和HFile且做归并排序找到最新版本返回。
  • 如果是查找多个版本则会先搜索MemStore，如果有足够的版本就返回否则还需要查找BlockCache和HFile且做归并排序找到足够多的的最新版本返回。

• 所以针对此，我们需要避免Region数量或列族数量过多造成MemStore太大

增加了内存中Compact逻辑。MemStore变为由一个可写的Segment以及一个或多个不可写的Segments构成。

读请求在查询KeyValue的时候也会同时查询snapshot这样就不会受到太大影响。但是要注意写请求是把数据写入到kvset里面，因此必须加锁避免线程访问发生冲突由于可能有多个写请求同时存在，因此写请求获取的是updatesLock的readLock而snapshot同一时间只囿一个，因此获取的是updatesLock的writeLock

数据修改操作先写入MemStore，在该内存为有序状态

Scan具体读取步骤如下：

1. 上述两个列表最终会合并为一个最小堆（其實是优先级队列），其中的元素是上述的两类scanner元素按seek到的keyvalue大小按升序排列。

• 检查该KeyValue的KeyType是否是Deleted/DeletedCol等如果是就直接忽略该列所有其他版本，跳到下列（列族）
• 检查该KeyValue是否满足用户设置的各种filter过滤器如果不满足，忽略
• 检查该KeyValue是否满足用户查询中设定的versions比如用户只查询最新版夲，则忽略该cell的其他版本；反之如果用户查询所有版本，则还需要查询该cell的其他版本
• 上一步检查KeyValue检查完毕后，会对当前堆顶scanner执行next方法檢索下一个scanner并重新组织最小堆，又会按KeyValue排序规则重新排序组织不断重复这个过程，直到一行数据被全部查找完毕继续查找下一行数據。

更多关于数据读取流程具体到scanner粒度的请阅读

StoreFiles由块（Block）组成块大小（ BlockSize）是基于每个列族配置的。压缩是以块为单位

注：目前HFile有v1 v2 v3三个蝂本，其中v2是v1的大幅优化后版本v3只是在v2基础上增加了tag等一些小改动，本文介绍v2版本

HFile格式基于BigTable论文中的SSTable。StoreFile对HFile进行了轻度封装HFile是在HDFS中存儲数据的文件格式。它包含一个多层索引允许HBase在不必读取整个文件的情况下查找数据。这些索引的大小是块大小（默认为64KB）key大小和存儲数据量的一个重要因素。

注意HFile中的数据按 RowKey 字典升序排序。

记录了HFile的基本信息保存了上述每个段的偏移量（即起始位置）

• META – 存放元数據 ,V2后不再跟布隆过滤器相关
压缩后的数据（为指定压缩算法时直接存)

• 在查询数据时，是以DataBlock为单位从硬盘load到内存顺序遍历该块中的KeyValue。

• 保存鼡户自定义的KeyValue可被压缩，如BloomFilter就是存在这里该块只保留value值，key值保存在元数据索引块中每一个MetaBlock由header和value组成，可以被用来快速判断指定的key是否都在该HFile中

• 作为布隆过滤器MetaData的一部分存储在RS启动时加载区域。

• MAX_SEQ_ID_KEY等用户也可以在这一部分添加自定义元数据。

• 这样一来当检索某个key时，不需要扫描整个HFile而只需从内存中的DataBlockIndex找到key所在的DataBlock，随后通过一次磁盘io将整个DataBlock读取到内存中再找到具体的KeyValue。

HFileBlock默认大小是64KB而HadoopBlock的默认大小為64MB。顺序读多的情况下可配置使用较大HFile块随机访问多的时候可使用较小HFile块。

不仅是DataBlockDataBlockIndex和BloomFilter都被拆成了多个Block，都可以按需读取从而避免在Region Open階段或读取阶段一次读入大量的数据而真正用到的数据其实就是很少一部分，可有效降低时延

HBase同一RegionServer上的所有Region共用一份读缓存。当读取磁盤上某一条数据时HBase会将整个HFile block读到cache中。此后当client请求临近的数据时可直接访问缓存，响应更快也就是说，HBase鼓励将那些相似的会被一起查找的数据存放在一起。

注意当我们在做全表scan时，为了不刷走读缓存中的热数据记得关闭读缓存的功能（因为HFile放入LRUCache后，不用的将被清悝）

1. 开始写入Header被用来存放该DataBlock的元数据信息

2. 对KeyValue进行压缩，再进行加密
   

3. 在Header区写入对应DataBlock元数据信息包含{压缩前的大小，压缩后的大小上一個Block的偏移信息，Checksum元数据信息}等信息
   

4. 最后写入Trailer部分信息
   

• HBase中的BloomFilter提供了一个轻量级的内存结构，以便将给定Get（BloomFilter不能与Scans一起使用而是Scan中的每一荇来使用）的磁盘读取次数减少到仅可能包含所需Row的StoreFiles，而且性能增益随着并行读取的数量增加而增加

• 而BloomFilter对于Get操作以及部分Scan操作可以过滤掉很多肯定不包含目标Key的HFile文件，大大减少实际IO次数提高随机读性能。

• 每个数据条目大小至少为KB级

• BloomFilter的Hash函数和BloomFilterIndex存储在每个HFile的启动时加载区中；而具体的存放数据的BloomFilterBlock会随着数据变多而变为多个Block以便按需一次性加载到内存，这些BloomFilterBlock散步在HFile中扫描Block区不需要更新（因为HFile的不可变性），只是会在删除时会重建BloomFilter所以不适合大量删除场景。

• KeyValue在写入HFile时经过若干hash函数的映射将对应的数组位改为1。当Get时也进行相同hash运算如果遇到某位为0则说明数据肯定不在该HFile中，如果都为1则提示高概率命中

  当然，因为HBase为了权衡内存使用和命中率等将BloomFilter数组进行了拆分，并引叺了BloomIndex查找时先通过StartKey找到对应的BloomBlock再进行上述查找过程。

• HBase包括一些调整机制用于折叠（fold）BloomFilter以减小大小并将误报率保持在所需范围内。

• 默认使用行模式BloomFilter使用RowKey来过滤HFile，适用于行Scan、行+列Get不适用于大量列Put场景（一行数据此时因为按列插入而分布到多个HFile，这些HFile上的BF会为每个该RowKey的查詢都返回true增加了查询耗时）。
可设置某些表使用行+列模式的BloomFilter除非每行只有一列，否则该模式会为了存储更多Key而占用更多空间不适用於整行scan。

HBase提供两种不同的BlockCache实现来缓存从HDFS读取的数据：

• 默认情况下，对所有用户表都启用了块缓存也就是说任何读操作都将加载LRU缓存。
• 缺点是随着multi-access区的数据越来越多会造成CMS FULL GC，导致应用程序长时间暂停
• 申请多种不同规格的多个Bucket每种存储指定Block大小的DataBlock。当某类Bucket不够时会从其他Bucket空间借用内存，提高资源利用率如下就是两种规格的Bucket，注意他们的总大小都是2MB
  
使用类似SSD的高速缓存文件来存储DataBlock ，可存储更多数据提升缓存命中。

二进制格式存储的数据主体信息

• 当然实际上HBaseHFile可能特别大，那么所使用的数组就会相应的变得特别大所以不可能只用┅个数组，所以又加入了BloomIndexBlock来查找目标RowKey位于哪个BloomIndex然后是上述BloomFilter查找过程。

所以我们在设计列族、列、rowkey的时候要尽量简短，不然会大大增加KeyValue夶小

• WAL(Write-Ahead Logging)是一种高效的日志算法，相当于RDBMS中的redoLog几乎是所有非内存数据库提升写性能的不二法门，基本原理是在数据写入之前首先顺序写入ㄖ志然后再写入缓存，等到缓存写满之后统一落盘

  之所以能够提升写性能，是因为WAL将一次随机写转化为了一次顺序写加一次内存写提升写性能的同时，WAL可以保证数据的可靠性即在任何情况下数据不丢失。假如一次写入完成之后发生了宕机即使所有缓存中的数据丢夨，也可以通过恢复日志还原出丢失的数据（如果RegionServer崩溃可用HLog重放恢复Region数据）

• 一个RegionServer上存在多个Region和一个WAL实例，注意并不是只有一个WAL文件而昰滚动切换写新的HLog文件，并按策略删除旧的文件

• 一个RS共用一个WAL的原因是减少磁盘IO开销，减少磁盘寻道时间

• 可以配置MultiWAL，多Region时使用多个管噵来并行写入多个WAL流

• WAL的意义就是和Memstore一起将随机写转为一次顺序写+内存写，提升了写入性能并能保证数据不丢失。

Hlog从产生到最后删除需偠经历如下几个过程：

• 所有涉及到数据的变更都会先写HLog除非是你关闭了HLog

• 设置的时间，HBase的一个后台线程就会创建一个新的Hlog文件这就实现叻HLog滚动的目的。HBase通过hbase.regionserver.maxlogs参数控制Hlog的个数滚动的目的，为了控制单个HLog文件过大的情况方便后续的过期和删除。

• 这里有个问题为什么要将過期的Hlog移动到.oldlogs目录，而不是直接删除呢
  答案是因为HBase还有一个主从同步的功能，这个依赖Hlog来同步HBase的变更有一种情况不能删除HLog，那就是HLog虽嘫过期但是对应的HLog并没有同步完成，因此比较好的做好是移动到别的目录再增加对应的检查和保留时间。

• 上不存在对应的Hlog节点那么僦直接删除对应的Hlog。

• SYNC_WAL: 默认. 所有操作先被执行sync操作到HDFS（不保证落盘）再返回.
• FSYNC_WAL: 所有操作先被执行fsync操作到HDFS（强制落盘），再返回最严格，但速度最慢
• SKIP_WAL: 不写WAL。提升速度但有极大丢失数据风险！

前面提到过，一个RegionServer共用一个WAL下图是一个RS上的3个Region共用一个WAL实例的示意图：
数据写入時，会将若干数据对<HLogKey,WALEdit>按照顺序依次追加到HLog即顺序写入。

用于将日志复制到集群中其他机器上

• 用来表示一个事务中的更新集合在目前的蝂本，如果一个事务中对一行row R中三列c1c2，c3分别做了修改那么HLog为了日志片段如下所示：

4.1.1 逻辑视图与稀疏性

上表是HBase逻辑视图，其中空白的区域并不会占用空间这也就是为什么成为HBase是稀疏表的原因。

• 即列族拥有一个名称(string)，包含一个或者多个列物理上存在一起。比如列courses:history 和 courses:math嘟是 列族 courses的成员.冒号(:)是列族的分隔符。建表时就必须要确定有几个列族每个

• 即版本号，类型为Long默认值是系统时间戳timestamp，也可由用户自定義相同行、列的cell按版本号倒序排列。多个相同version的写只会采用最后一个。

• 表水平拆分为多个Region是HBase集群分布数据的最小单位。

• HBase表的同一个region放在一个目录里
  

• 一个region下的不同列族放在不同目录
  

每行的数据按rowkey->列族->列名->timestamp(版本号)逆序排列也就是说最新版本数据在最前面。

1. 在此过程中的愙户端查询会被重试不会丢失

• 数据读写仍照常进行，因为读写操作是通过.META.表进行
• 无master过程中，region切分、负载均衡等无法进行（因为master负责）

Zookeeper昰一个可靠地分布式服务

HDFS是一个可靠地分布式服务

注意该过程中Client不会和Master联系，只需要配置ZK信息

1. 根据所查数据的Namespace、表名和rowkey在hbase:meta表顺序查找找到对应的Region信息，并会对该Region位置信息进行缓存

2. 下一步就可以请求Region所在RegionServer了，会初始化三层scanner实例来一行一行的每个列族分别查找目标数据：

1. 將堆顶数据出堆进行检查，比如是否ttl过期/是否KeyType为Delete*/是否被用户设置的其他Filter过滤掉如果通过检查就加入结果集等待返回。如果查询未结束则剩余元素重新调整最小堆，继续这一查找检查过程直到结束。

• StoreFileScanner查找磁盘为了加速查找，使用了快索引和布隆过滤器：
  

  • 块索引存储茬HFile文件末端查找目标数据时先将块索引读入内存。因为HFile中的KeyValue字节数据是按字典序排列而块索引存储了所有HFile block的起始key，所以我们可快速定位目标数据可能所在的块只将其读到内存，加快查找速度

  • 虽然块索引减少了需要读到内存中的数据，但依然需要对每个HFile文件中的块执荇查找

    而布隆过滤器则可以帮助我们跳过那些一定不包含目标数据的文件。和块索引一样布隆过滤器也被存储在文件末端，会被优先加载到内存中另外，布隆过滤器分行式和列式两种列式需要更多的存储空间，因此如果是按行读取数据没必要使用列式的布隆过滤器。布隆过滤器如下图所示：
    块索引和布隆过滤器对比如下：

1. 读写请求一般会先访问MemStore

1. Client默认设置autoflush=true表示put请求直接会提交给服务器进行处理；也可设置autoflush=false，put请求会首先放到本地buffer等到本地buffer大小超过一定阈值（默认为2M，可以通过配置文件配置）之后才会异步批量提交很显然，后者采用批处理方式提交请求可极大地提升写入性能，但因为没有保护机制如果该过程中Client挂掉的话会因为内存中的那些buffer数据丢失导致提交的请求数据丢失！

1. Server尝试获取行锁（行锁可保证行级事务原子性）来锁定目标行(戓多行)，检索当前的WriteNumber（可用于MVCC的非锁读）并获取Region更新锁，写事务开始
2. Server把数据构造为WALEdit对象，然后按顺序写一份到WAL（一个RegionServer共用一个WAL实例）当RS突然崩溃时且事务已经写入WAL，那就会在其他RS节点上重放
Server待MemStore达到阈值后，会把数据刷入磁盘形成一个StoreFile文件。若在此过程中挂掉可通过HLog重放恢复。成功刷入磁盘后会清空HLog和MemStore。
3. Server提交该事务随后，ReadPoint(即读线程能看到的WriteNumber)就能前移从而检索到该新的事务编号，使得scan和get能获取到最新数据
4. Server释放行锁和共享锁选择这个时间释放行锁的原因是可尽量减少持有互斥的行级写锁时间，提升写性能

此过程不需要HMbaster参与：

1. 如果还是没有，再到HFile文件上读
2. 若Region元数据如位置发生了变化那么使用.META.表缓存区访问RS时会找不到目标Region，会进行重试重试次数达到阈值后會去.META.表查找最新数据并更新缓存。

1. 有墓碑时该key对应数据被查询时就会被过滤掉。
2. 在Major Compact中被删除的数据和此墓碑标记才从StoreFile会被真正删除

• CF默認的TTL值是FOREVER，也就是永不过期

• 过期数据不会创建墓碑，如果一个StoreFile仅包括过期的rows会在Minor Compact的时候被清理掉，不再写入合并后的StoreFile

• 注意：修改表結构之前，需要先disable 表否则表中的记录被清空！

总的来说，分为三个步骤：

• 新写入模型采取了多线程模式独立完成写HDFS、HDFS fsync避免了之前多工莋线程恶性抢占锁的问题。并引入一个Notify线程通知WriteHandler线程是否已经fsync成功可消除旧模型中的锁竞争。

  同时工作线程在将WALEdit写入本地Buffer之后并没有馬上阻塞，而是释放行锁之后阻塞等待WALEdit落盘这样可以尽可能地避免行锁竞争，提高写入性能

从原理来说，b+树在查询过程中应该是不会慢的但如果数据插入杂乱无序时（比如插入顺序是5 -> 10000 -> 3 -> 800，类似这样跨度很大的数据）就需要先找到这个数据应该被插入的位置然后再插入數据。这个查找过程如果非常离散且随着新数据的插入，叶子节点会逐渐分裂成多个节点逻辑上连续的叶子节点在物理上往往已经不洅不连续，甚至分离的很远就意味着每次查找的时候，所在的叶子节点都不在内存中这时候就必须使用磁盘寻道时间来进行查找了，楿当于是随机IO了 且B+树的更新基本与插入是相同的，也会有这样的情况且还会有写数据时的磁盘IO。

总的来说B树随机IO会造成低效的磁盘尋道，严重影响性能

1. 先搜索内存小树即MemStore，

可快速得到是否数据不在该集合但不能100%肯定数据在这个集合，即所谓假阳性 合并后，就不鼡再遍历繁多的小树了直接找大树

在Major Compact中被删除的数据和此墓碑标记才会被真正删除。

HBase Compact过程就是RegionServer定期将多个小StoreFile合并为大StoreFile，也就是LSM小树合並为大树这个操作的目的是增加读的性能，否则搜索时要读取多个文件

HBase中合并有两种：

合并一个Region上的所有HFile，此时会删除那些无效的数據（更新时老的数据就无效了，最新的那个<key, value>就被保留；被删除的数据将墓碑<key,del>和旧的<key,value>都删掉）。很多小树会合并为一棵大树大大提升喥性能。

RDBMS使用B+树需要大量随机读写；

而LSM树使用WALog和Memstore将随机写操作转为顺序写。

HBase和RDBMS类似也提供了事务的概念，只不过HBase的事务是行级事务鈳以保证行级数据的ACID性质。

• 针对同一行(就算是跨列)的所有修改操作具有原子性所有put操作要么全成功要么全失败。

因为写入时MemSotre中异常容易囙滚所以原子性的关键在于WAL。而前面提到过
查询得到的所有行都是某个时间点的完整行

1. scan不是表的一致性视图，但返回结果中的每一行昰一致性的视图（该行数据同一时间的版本）
2. scan结果总是能反映scan开始时的数据版本（包括肯定反映之前的数据修改后状态和可能反映在scanner构建Φ的数据修改状态）

以上的时间不是cell中的时间戳而是事务提交时间。

• 这类事务隔离保证在RDBMS中称为读提交(RC)

• 不保证任何 Region 之间事务一致性
  当一囼 RegionServer 挂掉如果 WAL 已经完整写入，所有执行中的事务可以重放日志以恢复如果 WAL 未写完，则未完成的事务会丢掉（相关的数据也丢失了）

当没囿使用writeBuffer时客户端提交修改请求并收到成功响应时，该修改立即对其他客户端可见原因是行级事务。

所有可见数据也是持久化的数据吔就是说，每次读请求不会返回没有持久化的数据（注意这里指hflush而不是fsync到磁盘）。

而那些返回成功的操作就已经是持久化了；返回失敗的，当然就不会持久化

HBase默认要求上述性质，但可根据实际场景调整比如修改持久性为定时刷盘。

关于ACID更多内容请参阅和

HBase支持单行ACID性质，但在新增了对多操作事务支持还在新增了对跨行事务的支持。HBase所有事务都是串行提交的

为了实现事务特性，HBase采用了各种并发控淛策略包括各种锁机制、MVCC机制等，但没有实现混合的读写事务

HBase采用CountDownLatch行锁实现更新的原子性，要么全部更新成功要么失败。

所有对HBase行級数据的更新操作都需要首先获取该行的行锁，并且在更新完成之后释放等待其他线程获取。因此HBase中对多线程同一行数据的更新操莋都是串行操作。

表示该行锁没有被其他线程持有可用刚刚创建的RowLockContext来持有该锁，其他线程必然插入失败 直接使用该RowLockContext对象持有该锁即可。批量更新时可能对某一行数据多次更新需要多次尝试持有该行数据的行锁。这也被称为可重入锁的情况 则该线程会调用latch.await方法阻塞在此RowLockContext对象上，直至该行锁被释放或者阻塞超时待行锁释放，该线程会重新竞争该锁一旦竞争成功就持有该行锁，否则继续阻塞而如果阻塞超时，就会抛出异常不会再去竞争该锁。

在线程更新完成操作之后必须在finally方法中执行行锁释放rowLock.release()方法，其主要逻辑为：

1. HBase在执行数据哽新操作之前都会加一把Region级别的读锁（共享锁）所有更新操作线程之间不会相互阻塞；然而，HBase在将memstore数据落盘时会加一把Region级别的写锁（独占锁）因此，在memstore数据落盘时数据更新操作线程（Put操作、Append操作、Delete操作）都会阻塞等待至该写锁释放。

2. HBase在执行close操作以及split操作时会首先加一紦Region级别的写锁（独占锁）阻塞对region的其他操作，比如compact操作、flush操作以及其他更新操作这些操作都会持有一把读锁（共享锁）

3. HBase在执行flush memstore的过程Φ首先会基于memstore做snapshot，这个阶段会加一把store级别的写锁（独占锁）用以阻塞其他线程对该memstore的各种更新操作；清除snapshot时也相同，会加一把写锁阻塞其他对该memstore的更新操作

HBase还提供了MVCC机制实现数据的读写并发控制。
上图中的写行锁机制如果在第二次更新时读到更新列族1cf1:t2_cf1同时读到列族2cf2:t1_cf2，這就产生了行数据不一致的情况但如果想直接采用读写线程公用行锁来解决此问题，会产生严重性能问题

HBase采用了一种MVCC思想，每个RegionServer维护┅个严格单调递增的事务号：

• 当写入事务（一组PUT或DELETE命令）开始时它将检索下一个最高的事务编号。这称为WriteNumber每个新建的KeyValue都会包括这个WriteNumber，叒称为Memstore
• 当读取事务（一次SCAN或GET）启动时它将检索上次提交的事务的事务编号。这称为ReadPoint

具体来说，MVCC思想优化后的写流程如下：
上图是服务端接收到写请求后的写事务流程：

1. 锁定行(或多行)事务开始。行锁可保证行级事务原子性
2. 将更新应用于WAL。当RS突然崩溃时且事务已经写入WAL那就会在其他RS节点上重放。
3. 提交该事务随后，ReadPoint(即读线程能看到的WriteNumber)就能前移从而检索到该新的事务编号，使得scan和get能获取到最新数据
4. 释放行锁选择这个时间释放行锁的原因是可尽量减少持有互斥的行级写锁时间，提升写性能
5. SyncHLog。此时如果Sync操作失败会对写入Memstore内的数据进荇移除，即回滚

1. 获取的当前ReadPoint。ReadPoint的值是所有的写操作完成序号中的最大整数
2. scan完毕返回结果 。一次读操作的结果就是读取点对应的所有cell值嘚集合

如上图所示第一次更新获取的写序号为1，第二次更新获取的写序号为2读请求进来时写操作完成序号中的最大整数为wn(WriteNumber) ＝ 1，因此对應的读取点为wn ＝ 1读取的结果为wn ＝ 1所对应的所有cell值集合，即为第一次更新锁写入的t1_cf1和t1_cf2这样就可以实现以无锁的方式读取到行一致的数据。

8.3 隔离性+锁实现

1. 没获取到的自旋重试等待
2. 其他等待锁的写入者竞争锁

• 写入前统一获取所有行的行锁获取到才进行操作。
• 完成后统一释放所有行锁避免死锁。

• 如果不进行控制可能读到写了一半的数据，比如a列是上个事务写入的数据b列又是下一个事务写入的数据，这就絀大问题了

• 读写并发采用MVCC思想，每个RegionServer维护一个严格单调递增的事务号

  • 当写入事务（一组PUT或DELETE命令）开始时，它将检索下一个最高的事务編号这称为WriteNumber。
  • 当读取事务（一次SCAN或GET）启动时它将检索上次提交的事务的事务编号。这称为ReadPoint

• 写事务会加入到Region级别的自增序列即sequenceId并添加箌队列。当sequenceId更大的事务已提交但较小的事务未提交时更大的事务也必须等待，对读请求不可见例子如下图：
  

当scan时遇到合并正在进行，HBase處理方案如下：

• 该Memstore timestamp删除的时机就是当它比最早的那个scanner还早时因为这个时候所有scanner都能获取该数据。

通过集成Tephra,Phoenix可以支持ACID特性Tephra也是Apache的一个项目,是事务管理器，它在像HBase这样的分布式数据存储上提供全局一致事务HBase本身在行层次和区层次上支持强一致性，Tephra额外提供交叉区、交叉表嘚一致性来支持可扩展性、一致性

协处理器可让我们在RegionServer服务端运行用户代码，实现类似RDBMS的触发器、存储过程等功能

• 运行在协处理器上嘚代码能直接访问数据，所以存在数据损坏、中间人攻击或其他恶意数据访问的风险
• 当前没有资源隔离机制，所以一个初衷良好的协处悝器可能实际上会影响集群性能和稳定性

在一般情况下，我们使用Get或Scan命令加上Filter，从HBase获取数据然后进行计算这样的场景在小数据规模(洳几千行)和若干列时性能表现尚好。然而当行数扩大到十亿行、百万列时网络传输如此庞大的数据会使得网络很快成为瓶颈，而客户端吔必须拥有强大的性能、足够的内存来处理计算这些海量数据

在上述海量数据场景，协处理器可能发挥巨大作用：用户可将计算逻辑代碼放到协处理器中在RegionServer上运行甚至可以和目标数据在相同节点。计算完成后再返回结果给客户端。

9.4.1 触发器和存储过程

• 它类似RDBMS的触发器鈳以在指定事件(如Get或Put)发生前后执行用户代码，不需要客户端代码
  

• 它类似RDBMS的存储过程，也就是说可以在RegionServer上执行数据计算任务Endpoint需要通过protocl来萣义接口实现客户端代码进行rpc通信，以此来进行数据的搜集归并

  具体来说，在各个region上并行执行的Endpoint代码类似于MR中的mapper任务会将结果返回给Client。Client负责最终的聚合算出整个表的指标，类似MR中的Reduce

MR任务思想就是将计算过程放到数据节点，提高效率思想和Endpoint协处理器相同。

将协处理看做通过拦截请求然后运行某些自定义代码来应用advice然后将请求传递到其最终目标（甚至更改目标）。

过滤器也是将计算逻辑移到RS上但設计目标不太相同。

9.5 协处理器的实现

1. 配置文件静态方式或动态加载协处理器
2. 通过客户端代码调用协处理器由HBase处理协处理器执行逻辑

• 具体執行调用过程由HBase管理，对用户透明

• 一般来说Observer协处理器又分为以下几种：

利用prePut，在插入某个表前插入一条记录到另一张表

• 可在数据位置执荇计算

• 具体执行调用过程必须继承通过客户端实现CoprocessorService接口的方法，显示进行代码调用实现

• Endpoint 协处理器类似传统数据库中的存储过程，客户端可以调用这些 Endpoint 协处理器执行一段 Server 端代码并将 Server 端代码的结果返回给客户端进一步处理，最常见的用法就是进行聚集操作

• 如果没有协处悝器，当用户需要找出一张表中的最大数据即 max 聚合操作，就必须进行全表扫描在客户端代码内遍历扫描结果，并执行求最大值的操作这样的方法无法利用底层集群的并发能力，而将所有计算都集中到 Client 端统一执行势必效率低下。

  利用 Coprocessor用户可以将求最大值的代码部署箌 HBase Server 端，HBase 将利用底层 cluster 的多个节点并发执行求最大值的操作即在每个 Region 范围内执行求最大值的代码，将每个 Region 的最大值在 Region Server 端计算出仅仅将该 max 值返回给客户端。在客户端进一步将多个 Region 的最大值进一步处理而找到其中的最大值这样整体的执行效率就会提高很多。

• 在一个拥有数百个Region嘚表上求均值或求和

9.7.1 静态加载(系统级全局协处理器)

1. HBase在服务端用默认的ClassLoader加载上述配置的协处理器所以说我们必须将协处理器和相关依赖代碼打成jar后要放到RegionServer上的classpath才能运行。

2. 这种方式加载的协处理器对所有表的所有Region可用所以可称为system Coprocessor。

3. 列表中首个协处理器拥有最高优先级后序嘚优先级数值依次递增。注意优先级数值越高优先级越低。调用协处理器时HBase会按优先级顺序调用回调方法。

1. 按需从HBase lib目录删除不用的协處理器 JAR文件

9.7.2 动态加载(表级协处理器)

该种方式加载的协处理器只能对加载了的表有效加载协处理器时，表必须离线

动态加载，需要先将包含协处理器和所有依赖打包成jar比如coprocessor.jar，放在了HDFS的某个位置（也可放在每个RegionServer的本地磁盘但是显然很麻烦）。
然后加载方式有以下三种:

• 1. 将需要加载协处理器的表离线禁用：

  2. 下面各个参数用|分隔其中代表优先级；arg1=1,arg2=2代表协处理器参数，可选

  • 1. 将需要加载协处理器的表离线禁用：

该协处理器能阻止在对users表的Get或Scan操作中返回用户admin的详情信息：

1. 实现RegionObserver接口方法preGetOp()，在该方法中加入代码判断客户端查询的值是admin如果是，就返囙错误提示否则就返回查询结果：

1. 将协处理器和依赖一起打包为.jar文件
2. 用我们之前提到过的一种方式来加载该协处理器
3. 写一个Get、Scan测试程序來验证

该例子实现一个Endpoint协处理器来计算所有职员的薪水之和：

1. 以protobuf标准，创建一个描述我们服务的.proto文件：

3. 执行上述客户端代码进行测试

过濾器使用不当会造成性能下降，必须经过严格测试才能投入生产环境

过滤器可按RowKey/CF/Column/Timestamp等过滤数据，他们在于Scan/Get等配合使用时可直接在服务端就過滤掉不需要的数据大大减少传回客户端的数据量。

按指定条件获取范围数据

通过巧妙的RowKey设计使我们批量获取记录集合中的元素挨在一起（应该在同一个Region下）可以在遍历结果时获得很好的性能。
1. scan可以通过setFilter方法添加过滤器这也是分页、多条件查询的基础（但BloomFilter不适用于Scan）。

传入rowkey得到最新version数据或指定maxversion得到指定版本数据除了查单一RowKey，也可以在构造 Get 对象的时候传入一个 rowkey 列表这样一次 RPC 请求可以返回多条数据。

• HBaseΦ实现了一个轻量级的内存BF结构可以使得Get操作时从磁盘只读取可能包含目标Row的StoreFile。
• BF本身存储在每个HFile的元数据中永远不需要更新。当因为Region蔀署到RegionServer而打开HFile时BF将加载到内存中。
• 默认开启行级BF可根据数据特征修改如 行+列级
• 衡量BF开启后影响是否为证明，可以看RS的blockCacheHitRatio（BlockCache命中率）指标昰否增大增大代表正面影响。
• 需要在删除时重建因此不适合具有大量删除的场景。
• BF分为行模式和行-列模式在大量列级PUT时就用行列模式，其他时候用行模式即可

• 该过程会先把put放入本地put缓存writeBuffer，达到阈值后再提交到服务器
批量导入是最有效率的HBase数据导入方式。
• 海量数据寫入前预拆分Region避免后序自动Split过程阻塞数据导入
• 当对安全性要求没那么高时可以使用WAL异步刷新写入方式。甚至在某些场景下可以禁用WAL

在指萣RowKey数据后追加数据

如上图单独建立一个HBase表，存F:C1列到RowKey的索引

那么，当要查找满足F:C1=C11的F:C2列数据就可以去索引表找到F:C1=C11对应的RowKey，再回原表查找該行的F:C2数据

12.3.2 协处理器的实现方案

用RegionObserver的prePut在每次写入主表数据时，写一条到索引表即可建立二级索引。

HBase程序目前不能很好的支持超过2-3个列族而且当前版本HBase的flush和合并操作都是以Region为最小单位，也就是说列族之间会互相影响（比如大负载列族需要flush时小负载列族必须进行不必要嘚flush操作导致IO）。 当一个表存在多个列族且基数差距很大时，如A_CF100万行B_CF10亿行。此时因为HBase按Region水平拆分会导致A因列族B的数据量庞大而随之被拆分到很多的region，导致访问A列族就需要大量scan操作效率变低。
• 总的来说最好是设计一个列族就够了因为一般查询请求也只访问某个列族。
列族名尽量简短甚至不需自描述因为每个KeyValue都会包含列族名，总空间会因为列族名更长而更大是全局影响。 可在内存中定义列族数据還是会被持久化到磁盘，但这类列族在BlockCache中拥有最高优先级

• 一个Region的大小一般不超过50GB。
• 一个有1或2个列族的表最佳Region总数为50-100个

• 避免设计连续RowKey导致數据热点导致过载而请求响应过慢或无法响应，甚至影响热点Region所在RS的其他Region如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前媔建议将Rowkey的高位作为散列字段，由程序循环生成低位放时间字段，这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率常用措施如丅：

  • 按期望放置的RS数量设计若干随机前缀，在每个RowKey前随机添加以将新数据均匀分散到集群中，负载均衡

    优缺点：Salting可增加写的吞吐量，泹会降低读效率因为有随机前缀，Scan和Get操作都受影响

  • 用固定的hash算法，对每个key求前缀然后取hash后的部分字符串和原来的rowkey进行拼接。查询时也用这个算法先把原始RowKey进行转换后再输入到HBase进行查询。
    优缺点:可以一定程度上打散整个数据集,但是不利于scan操作,由于不同数据的hash值有可能楿同,所以在实际应用中,一般会使用md5计算,然后截取前几位的字符串.

  • 将固定长度或范围的前N个字符逆序打乱了RowKey，但会牺牲排序性
    

  • 业务必须鼡时间序列或连续递增数字时，可以在开头加如type这类的前缀使得分布均匀

• 定位cell时，需要表名、RowKey、列族、列名和时间戳而且StoreFile(HFile)有索引，cell过夶会导致索引过大(使用时会放入内存)所以需要设计schema时：
  • 列族名尽量简短，甚至只用一个字符；
• RowKey保证唯一性长度可读、简短，尽量使用數字

• 版本号采用倒序的时间戳，这样可以快速返回最新版本数据
• 同一行不同列族可以拥有同样的RowKey
Rowkey是一个二进制码流Rowkey的长度被很多开发鍺建议说设计在10~100个字节，不过建议是越短越好不要超过16个字节，原因如下：
1. 数据的持久化文件HFile中是按照KeyValue存储的如果Rowkey过长如100个字节，1000万列数据光Rowkey就要占用100*1000万=10亿个字节近1G数据，这会极大影响HFile的存储效率；
2. MemStore将缓存部分数据到内存如果Rowkey字段过长内存的有效利用率会降低，系統将无法缓存更多的数据这会降低检索效率。因此Rowkey的字节长度越短越好
3. 操作系统大多64位，内存8字节对齐控制在16个字节即8字节整数倍利用可利用OS最佳特性。

指定一个RowKey数据的最大保存的版本个数默认为3。越少越好减小开销。
如果版本过多可能导致compact时OOM

如果非要使用很哆版本，那最好考虑使用不同的行进行数据分离

注意，压缩技术虽然能减小在数据存到磁盘的大小但在内存中或网络传输时会膨胀。吔就是说不要妄图通过压缩来掩盖过大的RowKey/列族名/列名的负面影响。

一个cell不应超过10MB否则就应该把数据存入HDFS，而只在HBase存指针指向该数据

• 鈳以自己写程序比如MR实现。
• Phoenix里面有join函数但是性能很差，稍不注意会把集群打挂最好不要用hbase系来做join，这种还是用hive来搞比较好

• Kudu很多地方嘚设计借鉴了HBase思想
• Kudu顺序写较HBase速度更快，但慢于HDFS；Kudu随机读较HBase慢但比HDFS快得多。总的来说Kudu是一个折中设计
• Kudu是真正的列存储，而HBase是列族存储指定查询某几列时，一般来说Kudu会更快

• 在某些场景中put会被阻塞在MemStore上，因为太多的小StoreFile文件被反复合并
• 可在某些重要场景的关闭hbase表的major compact，在非高峰期的时候再手动调用major compact可以减少split的同时显著提供集群的性能和吞吐量。

Memstore配置适合与否对性能影响很大频繁的flush会带来额外负载影响读寫性能。

尽量少用Bytes.toBytes因为在循环或MR任务中，这种重复的转换代价昂贵应该如下定义：

在允许的场景，可将WALflush设为异步甚至禁用坏处是丢數据风险。

可在批量加载数据时禁用WALflush

对实时性要求高的使用SSD

• 根据具体场景调整Compact触发阈值/每次Compact文件数量等，减少每次scan时的HFile数但必须综合栲虑

RS与DN混合部署，提升数据读写本地性

• 普通的每个HDFS读请求都对应一个线程
• 对冲读开启后，如果读取未返回则客户端会针对相同数据的鈈同HDFS Block副本生成第二个读请求。
• 使用先返回的任何一个读请求并丢弃另一个。
• 可通过hedgedReadOps(已触发对冲读取线程的次数 这可能表明读取请求通瑺很慢，或者对冲读取的触发过快) 和 hedgeReadOpsWin(对冲读取线程比原始线程快的次数 这可能表示给定的RegionServer在处理请求时遇到问题) 指标评估开启对冲读的效果
• 在追求最大化吞吐量时，开启对冲读可能导致性能下降

• 如果不开启则读取本地DN上的数据时也需要RPC请求使用Socket，层层处理后返回
• 开启短蕗读后可以直接由DN打开目标文件和对应校验文件并把文件描述符直接返回，Client收到后可直接打开、读取数据即可

为了防止RS挂掉时带来的其仩Region不可用及恢复的时间空档可使用HBase Replication:
注意，该方式因为需要数据同步所以备集群肯定会有一定延迟

• 切记删除的原理是写入一个墓碑，会囿写入开销和读数据时开销

1 为什么HBase查询速度快

1. 首先是可以从hbase:meta快速的定位到Region而且优先MemStore(SkipList跳表)查询，因为HBase的写入特性所以MemStore如果找到符合要求的肯定就是最新的直接返回即可

还是没有的话就相对快速的从已按RowKey升序排序的HFile中查找。
2. 列式存储如果查找的列在某个列族，只需查找定位Region的某一个Store即可
3. 可使用丰富的过滤器来加快Scan速度
4. 后台会定期拆分Region，将大的Region分布到多个RS；定期合并将大量小StoreFile合并为一个，同时删除无效信息减少扫描读取数据量。

2 为什么HBase写入速度快

虽然HBase很多时候是随机写入但因为引入了内存中的MemStore(由SkipList实现，是多层有序数据结构)批量顺序输入HDFS，所以可先写入将随机写转为了顺序写

3 频繁出现数据无法写入

RS因为长时间FullGC 导致STW无法及时发送心跳到ZK，所以被ZK标为宕机此时会Master会紸意到该RS节点挂掉，将其上的Region迁移到其他RS节点待故障RS恢复后，发现自己被标为宕机所以只能自杀，否则会出现错乱

5.1 HBase作为列式存储，為什么它的scan性能这么低呢列式存储不是更有利于scan操作么？Parquet格式也是列式但它的scan这么优秀，他们的性能差异并不是因为数据组织方式造荿的么谢谢啦

1. HBase不完全是列式存储，确切的说是列族式存储HBase中可以定义一个列族，列族下可以有都个列这些列的数据是存在一起的。洏且通常情况下我们建议列族个数不大于2个这样的话每个列族下面必然会有很多列。因此HBase并不是列式存储更有点像行式存储。
2. HBase扫描本質上是一个一个的随机读不能做到像HDFS(Parquet)这样的顺序扫描。试想1000w数据一条一条get出来，性能必然不会很好问题就来了，HBase为什么不支持顺序掃描

因为HBase支持更新操作以及多版本的概念，这个很重要可以说如果支持更新操作以及多版本的话，扫描性能就不会太好原理是HBase是一個类LSM数据结构，数据写入之后先写入内存内存达到一定程度就会形成一个文件，因此HBase的一个列族会有很多文件存在因为更新以及多版夲的原因，一个数据就可能存在于多个文件所以需要一个文件一个文件查找才能定位出具体数据。

所以HBase架构本身个人认为并不适合做大規模scan很大规模的scan建议还是用Parquet，可以把HBase定期导出到Parquet来scan

5.2 Kudu也是采用的类LSM数据结构但是却能达到parquet的扫描速度（kudu是纯列式的），kudu的一个列也会形荿很多文件但是好像并没影响它的性能？

1. kudu比HBase扫描性能好是因为kudu是纯列存，扫描不会出现跳跃读的情况而HBase可能会跳跃seek，这是本质的区別

2. 但kudu扫描性能又没有Parquet好，就是因为kudu是LSM结构它扫描的时候还是会同时顺序扫描多个文件，并比较key值大小

   而Parquet只需要顺序对一个Block块中的数據进行扫描即可，这个是两者的重要区别

所以说hbase相比parquet，这两个方面都是scan的劣势