这样，当添加一个新的节点时，只需将每个节点上部分数据移动给新节点，同时修改一 下该表即可。 Thrift：Thrift 是一个跨语言的 RPC 框架，分别解释“RPC”和“跨语言”如下：RPC 是远程过程调用，其使用方式与调用一个普通函数一样，但执行体发生在远程机器上；跨语 言是指不同语言之间进行通信，比如 C/S 架构中，Server 端采用 C++编写，Client 端采用 PHP 编写，怎样让两者之间通信，Thrift 是一种很好的方式。 本篇最前面的几道题均可以映射到以上几个系统的某个模块中，如：
1）关于高并发系统设计，主要有以下几个关键技术点：缓存、索引、数据分片及锁粒 度尽可能小。
2）题目 2 涉及现在通用的分布式文件系统的副本存放策略。一般是将大文件切分成小 的 block（如 64MB）后，以 block 为单位存放三份到不同的节点上，这三份数据的位置需根 据网络拓扑结构配置，一般而言，如果不考虑跨数据中心，可以这样存放：两个副本存放在 同一个机架的不同节点上，而另外一个副本存放在另一个机架上，这样从效率和可靠性上， 都是最优的（这个 Google 公布的文档中有专门的证明，有兴趣的可参阅一下）。如果考虑跨 数据中心，可将两份存在一个数据中心的不同机架上，另一份放到另一个数据中心。
3）题目 4 涉及 BigTable 的模型。主要思想是将随机写转化为顺序写，进而大大提高写 速度。具体是：由于磁盘物理结构的独特设计，其并发的随机写（主要是因为磁盘寻道时间 长）非常慢，考虑到这一点，在 BigTable 模型中，首先会将并发写的大批数据放到一个内存 表（称为“memtable”）中，当该表大到一定程度后，会顺序写到一个磁盘表（称为“SSTable”） 中，这种写是顺序写，效率极高。此时可能有读者问，随机读可不可以这样优化？答案是： 看情况。通常而言，如果读并发度不高，则不可以这么做，因为如果将多个读重新排列组合 后再执行，系统的响应时间太慢，用户可能接受不了，而如果读并发度极高，也许可以采用 类似机制。
经验技巧 7 如何解决求职中的时间冲突问题？
对于求职者而言，求职季就是一个赶场季，一天少则几家、十几家企业入校招聘，多则 几十家、上百家企业招兵买马，企业多，选择项自然也多，这固然是一件好事情，但由于招 聘企业实在是太多，自然而然会导致另外一个问题的发生：同一天企业扎堆，且都是自己心 仪或欣赏的大牛企业的现象。如果不能够提前掌握企业的宣讲时间、地点，是很容易迟到或 错过的。但有时候即使掌握了宣讲时间、笔试和面试时间，还是有可能错过，为什么呢？时 间冲突，人不可能具有分身术，也不可能同一时间做两件不同的事情，所以，很多时候就必 须有所取舍了。 到底该如何取舍呢？该如何应对这种时间冲突的问题呢？在此，编者将自己的一些想法 和经验分享出来，以供读者参考：
1）如果多家心仪企业的校园宣讲时间发生冲突（前提是只宣讲，不笔试，否则请看后面 的建议），此时最好的解决方法是和同学或朋友商量好，各去一家，然后大家进行信息共享。