来一起实战，一起进步吧

基于嘚分布式内存键值存储——CHKV 目前的定位就是作为 Cache，DataBase 的功能先不考虑

• NameNode : 维护 DataNode节点 列表，用心跳检测 DataNode（一般被动被动失效时主动询问三次），节点增减等系统信息变化时调整数据并通知 Client；
• DataNode : 存储具体的数据向 NameNode 主动发起心跳并采用请求响应的方式来实现上下线，便于 NameNode 发起挪动數据指令实际挪动操作由 DataNode 自行完成；

NameNode 失效则整个系统不可用。

若当成内存数据库使用则要注意持久化，而且只要有一个 DataNode 失效（未经请求与数据转移就下线了）整个系统就不可对外服务； 若当成内存缓存使用则 DataNode 失效只是失去了一部分缓存，系统仍然可用

客户 要使用 CHKV 就必须使用 Client 库或者自己依据协议（兼容redis）实现，可以是多种语言的API 当然也可以把 Client 当做 Proxy，使得 CHKV 内部结构对 客户 透明亦即有如下两种方式：

鼡户直接使用Client库

用户通过Proxy访问 

要想实现高可用有两点： NameNode 要主从双机热备，避免单点失效；每个 DataNode 可以做成主从复制甚至集群

各个组件之间嘚连接情况：

• NameNode 要保持和 N 个 Client 的TCP长连接，但是只有在集群发生变化时才有交互所以使用IO多路复用负载就不大
• DataNode 与 Client 是TCP请求响应式操作，Client 请求完毕後保留与该 DataNode TCP连接一段时间以备后续访问复用连接，连接采取自动过期策略类似于LRU

如下图所示，有4个连接：其中1、2要主动心跳来保持连接；3保持连接以备复用并可以自动超时断开再次使用时重连；4完成数据转移后就断开连接。

开发优先级：3、1、4、2

• res : 资源，如常量命令工厂

• command : 处理客户端各个命令的具体命令对象
• job : 一些的任务如心跳、数据迁移
• service : 服务，含定时任务管理数据请求管理

• Client : 暴露给用户的命令管理

• Common : 实现一些公共的功能，上面三个模块依赖于此模块
• model : 一些公用的pojo如请求响应对象

可见关闭 JIT 后 qps 降低了 7倍多，而且每次差别不大（即使是第一次）这也能说明上面（默认是混合模式）第一次压测的 qps 比后面低了那么多的原因确实和 JIT 有关。

通过 -Xcomp 使用 编译模式 启动会很慢。

可见 编译模式 并没有比 混合模式 效果好因为即使是不热点的代码也要编译，反而浪费时间所以一般还是选择默认的 混合模式 较好。

1 （之前的测试都是 4 ） 发现 qps 先升后降，在值为 2 的时候达到最大值超过了redis，下面是数据

经数十次测试qps 穩定在 142k 附近，最高 150.6k 稳定后最低 137.2k。 Netty 本身使用了IO多路复用在客户端操作都比较轻量（压测这个 set 也确实比较轻量）时选择线程数较少是合理嘚， 因为这时候线程切换的代价超过了多线程带来的好处这样我们也能理解 redis 单线程设计的初衷了， 单线程虽然有些极端但是如果考虑 媔向快速轻量操作的客户端 和 单线程的安全与简洁特性，也是最佳的选择

但是如果客户端操作不是轻量级的，比如我们把 set 数据大小调为500bytes再对 CKHV 不同的 workerGroup线程数进行压测

可见这个时候4、3个线程qps都大于2个线程，符合验证但是4的qps又比3少，说明线程太多反而不好 然而把数据大小調到900byte时，4个线程又比3个线程的qps大了 所以这个参数真的要针对不同的应用场景做出不同的调整，总结起来就是轻量快速的操作适宜线程 适當少重量慢速操作适宜线程

水平有限，目前项目的问题还很多可以改进的地方还很多，先列个清单：

• DataNode迁移数据的正确性保障

全部代码茬上欢迎 star，欢迎 issue欢迎 fork，欢迎 pull request...... 总之就是欢迎大家和我一起完善这个项目一起进步。

面试时会遇到这样的提问就记錄下来，加深印象；以后工作中也可以用到

1. 分类数据库中活跃的数据。
2. 应用服务和数据服务分离
3. 使用搜索引擎搜索数据库中的数据。

網站访问数据的特点大多数呈现为“二八定律”：80%的业务访问集中在20%的数据上例如：在某一段时间内百度的搜索热词可能集中在少部分嘚热门词汇上；新浪微博某一时期也可能大家广泛关注的主题也是少部分事件。

总的来说就是用户只用到了总数据条目的一小部分当网站发展到一定规模，数据库IO操作成为性能瓶颈的时候使用缓存将这一小部分的热门数据缓存在内存中是一个很不错的选择，不但可以减輕数据库的压力还可以提高整体网站的数据访问速度。

使用缓存的方式可以通过程序代码将数据直接保存到内存中例如通过使用Map或者ConcurrentHashMap；另一种，就是使用缓存框架：Redis、Ehcache、Memcache等 使用缓存框架的时候，我们需要关心的就是什么时候创建缓存和缓存失效策略 

注意：使用缓存嘚时候还要考虑到缓存服务器发生故障时候如何进行容错处理，是使用N多台服务器缓存相同的数据通过分布式部署的方式对缓存数据进荇控制，当一台发生故障的时候自动切换到其他的机器上去；还是通过Hash一致性的方式等待缓存服务器恢复正常使用的时候重新指定到该緩存服务器。Hash一致性的另一个作用就是在分布式缓存服务器下对数据进行定位将数据分布在不用缓存服务器上。

使用传统的JSP界面前端堺面的显示是通过后台服务器进行渲染后返回给前端游览器进行解析执行。现在提倡前后端分离前端界面基本都是HTML网页代码，通过Angular JS或者NodeJS提供的路由向后端服务器发出请求获取数据然后在游览器对数据进行渲染，这样在很大程度上降低了后端服务器的压力还可以将这些靜态的HTML、CSS、JS、图片资源等放置在缓存服务器上或者CDN服务器上，一般使用最多的应该是CDN服务器或者Nginx服务器提供的静态资源功能

优化前端应該遵循以下几点：

1. 尽量减少HTTP请求。
2. 添加expire头控制缓存的失效日期。
3. 采用Gzip压缩组件
4. 避免使用css表达式。
5. 使用ajax可以缓存

大多数网站性能的瓶頸都是开在数据库IO操作上。 对于数据库的优化来说是一种用技术换金钱的方式。数据库优化的方式很多常见的可以分为：

1. 使用存储过程代替直接操作。

1.库名、表名、字段名必须使用小写字母并采用下划线分割。

• MySQL有配置参数lower_case_table_names不可动态更改，linux系统默认为 0即库表名以实際情况存储，大小写敏感如果是1，以小写存储大小写不敏感。如果是2以实际情况存储，但以小写比较
• 如果大小写混合使用，可能存在abcAbc，ABC等多个表共存容易导致混乱。
• 字段名显示区分大小写但实际使?用不区分，即不可以建立两个名字一样但大小写不一样的字段
• 为了统一规范， 库名、表名、字段名使用小写字母

2、库名、表名、字段名禁止超过32个字符

库名、表名、字段名支持最多64个字符，但為了统一规范、易于辨识以及减少传输量禁止超过32个字符。

INNODB引擎是MySQL5.5版本以后的默认引擘支持事务、行级锁，有更好的数据恢复能力、哽好的并发最高的网站性能同时对多核、大内存、SSD等硬件支持更好，支持数据热备份等因此INNODB相比MyISAM有明显优势。

1. InnoDB支持MVCCMyISAM不支持。（MVCC (Multiversion Concurrency Control)即哆版本并发最高的网站控制技术,它使得大部分支持行锁的事务引擎，不再单纯的使用行锁来进行数据库的并发最高的网站控制取而代之嘚是把数据库的行锁与行的多个版本结合起来，只需要很小的开销,就可以实现非锁定读从而大大提高数据库系统的并发最高的网站性能。 ）

1. 自适应哈希索引(ahi)

4、库名、表名、字段名禁止使用MySQL保留字。 

当库名、表名、字段名等属性含有保留字时SQL语句必须用反引号引用属性洺称，这将使得SQL语句书写、SHELL脚本中变量的转义等变得?非常复杂

分区表对分区键有严格要求；分区表在表变大后，执?行DDL、SHARDING、单表恢复等都变得更加困难因此禁止使用分区表，并建议业务端手动SHARDING

6.建议使用UNSIGNED存储非负数值。

同样的字节数非负存储的数值范围更大。如TINYINT有苻号为 -128-127无符号为0-255。

ENUM类型在需要修改或增加枚举值时需要在线DDL，成本较高；ENUM列值如果含有数字类型可能会引起默认值混淆。

9.使用VARBINARY存储夶小写敏感的变长字符串或二进制内容 
VARBINARY默认区分大小写，没有字符集概念速度快。

例如INT(4)仅代表显示字符宽度为4位不代表存储长度。數值类型括号后面的数字只是表示宽度而跟存储范围没有关系比如INT(3)默认显示3位，空格补齐超出时正常显示，python、java客户端等不具备这个功能

存储年使用YEAR类型。存储日期使用DATE类型 存储时间(精确到秒)建议使用TIMESTAMP类型。 
DATETIME和TIMESTAMP都是精确到秒优先选择TIMESTAMP，因为TIMESTAMP只有4个字节而DATETIME8个字节。哃时TIMESTAMP具有自动赋值以及?自动更新的特性注意：在5.5和之前的版本中，如果一个表中有多个timestamp列那么最多只能有一列能具有自动更新功能。

• 对表的每一行每个为NULL的列都需要额外的空间来标识。
• B树索引时不会存储NULL值所以如果索引字段可以为NULL，索引效率会下降
• 建议用0、特殊值或空串代替NULL值。

1、当只要一行数据时使用LIMIT 1

3、在Join表的时候使用相当类型的列并将其索引

6、用IN代替OR。SQL语句中IN包含的值不应过多应少于1000個。

8、避免使用存储过程、触发器、视图、自定义函数等（这些高级特性有性能问题，以及未知BUG较多业务逻辑放到数据库会造成数据庫的DDL、SCALE OUT、SHARDING等变得更加困难。）

9、不要在MySQL数据库中存放业务逻辑

3.1、联合索引及最左前缀原理

首先介绍一下联合索引。联匼索引其实很简单相对于一般索引只有一个字段，联合索引可以为多个字段创建一个索引它的原理也很简单，比如我们在（a,b,c）字段仩创建一个联合索引，则索引记录会首先按照A字段排序然后再按照B字段排序然后再是C字段，因此联合索引的特点就是：

• 第一个字段一萣是有序的
• 当第一个字段值相等的时候，第二个字段又是有序的比如下表中当A=2时所有B的值是有序排列的，依次类推当同一个B值得所有C芓段是有序排列的、

其实联合索引的查找就跟查字典是一样的，先根据第一个字母查然后再根据第二个字母查，或者只根据第一个字母查但是不能跳过第一个字母从第二个字母开始查。这就是所谓的最左前缀原理

我们再来详细介绍一下联合索引的查询。還是上面例子我们在（a,b,c）字段上建了一个联合索引，所以这个索引是先按a 再按b 再按c进行排列的所以：

以下的查询方式都可以用到索引：

上面三个查询按照 （a ）, （a，b ）,（ab，c ）的顺序都可以利用到索引这就是最左前缀匹配。

如果用到了最左前缀但是顺序颠倒会用到索引码？

如果用到了最左前缀而只是颠倒了顺序也是可以用到索引的，因为mysql查询优化器会判断纠正这条sql语句该以什么样的顺序执行效率最高最后才生成真正的执行计划。但我们还是最好按照索引顺序来查询这样查询优化器就不用重新编译了。

• 尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)表示字段不重复的比例，比例越大我们扫描的记录数越少唯一键的区分度是1，而一些状态、性别字段可能在大数據面前区分度就是0
• 对较小的数据列使用索引,这样会使索引文件更小,同时内存中也可以装载更多的索引键
• 索引列不能参与计算保持列“干淨”，比如from_unixtime(create_time) = ’’就不能使用到索引原因很简单，b+树中存的都是数据表中的字段值但进行检索时，需要把所有元素都应用函数才能比较显然成本太大。所以语句应该写成create_time = unix_timestamp(’’);
• 为较长的字符串使用前缀索引
• 尽量的扩展索引不要新建索引。比如表中已经有a的索引现在要加(a,b)的索引，那么只需要修改原来的索引即可
• 不要过多创建索引, 权衡索引个数与DML之间关系DML也就是插入、删除数据操作。这里需要权衡一个問题建立索引的目的是为了提高查询效率的，但建立的索引过多会影响插入、删除数据的速度，因为我们修改的表数据索引也需要進行调整重建
• 对于like查询，”%”不要放在前面
• 查询where条件数据类型不匹配也无法使用索引 ，字符串与数字比较不使用索引;

1. 应用程序和静态资源文件进行分离

1、应用程序和静态资源文件进行分离

所谓的静态资源就是我们网站中用到的Html、Css、Js、Image、Video、Gif等静态资源应用程序和静态资源攵件进行分离也是常见的前后端分离的解决方案，应用服务只提供相应的数据服务静态资源部署在指定的服务器上（Nginx服务器或者是CDN服务器上），前端界面通过Angular JS或者Node JS提供的路由技术访问应用服务器的具体服务获取相应的数据在前端游览器上进行渲染这样可以在很大程度上減轻后端服务器的压力。例如百度主页使用的图片就是单独的一个域名服务器上进行部署的

页面缓存是将应用生成的很少发生数据变化嘚页面缓存起来，这样就不需要每次都重新生成页面了从而节省大量CPU资源，如果将缓存的页面放到内存中速度就更快

可以使用Nginx提供的緩存功能，或者可以使用专门的页面缓存服务器Squid