分布式消息队列

1. 为什么要在系统中加入消息队列

• 系统解耦
• 可靠投递
• 流量控制
• 广播
• 最终一致性
• 耗时操作

2. 比较热门的消息队列

• ActiveMQ [Apache维护]
• RabbitMQ [Erlang编写]
• RocketMQ [阿里维护]
• Jafka/Kafka[apache] 
  分布式消息系统，由LinkedIn于2010年开源。scala语言编写。低延迟的发送和收集大量的事件和日志数据。
• mq[alibaba]

插入一点数据库知识点

3. 数据库拆分类型

• 垂直拆分 
  把关联性不强的表拆分到不同的dbserver
• 水平拆分 
  适用于单表数据量很大的时候.根据字段来拆分.如根据userid再哈希分表.把不同字段分到不同的库中.常用字段和不常用字段分开存储.

4. 拆分之后面临的问题

a. 事务问题

• 使用分布式事务[细节] 
  由数据库管理事务,这样性能代价高!
• 由应用程序和数据库共同控制 
  将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务，并通过应用程序来总控各个小事务。性能有优势.需要应用程序在事务控制上做灵活设计。如果使用了spring的事务管理，改动起来会面临一定的困难。

b. 跨节点join

• 解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。

c. 跨节点的count,order by,group by以及聚合函数问题

• 这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。

4. 大型网站优化

• 前端优化 
  减少http请求/用了脚本合并js/css代码 
  使用浏览器缓存 
  启用Gzip压缩
• CDN加速
• 反向代理 
  主要有两个作用 
  1.安全.2.反向代理服务器缓存 
  正向代理主要是为了浏览器的安全.反向代理是为了服务器安全
• 服务端缓存 
  缓存的本质是内存哈希表

5. spring 优缺点分析

• 难以调试
• 配置文件方面，增加了额外的开发和维护工作。
• 程序的逻辑性和可读性确实降低
• 使用引入了新的复杂度,小型项目引入Spring简直是噩梦
• 4，感觉引入了Spring的项目，很难从Spring中脱离出来，我认为Spring对项目的耦合太过紧密，就像一个强有力的皮搋子吸住马桶口不放开。 
  这点严重同意，神马“非侵入框架”，都是骗人的，不说别的，你就光把你项目中的配置文件全换一遍试试？配置文件这玩意儿，多了也算是侵入，我曾经所在的某个项目，各种配置文件加起来的维护难度，已经大大超过代码了。代码起码还有eclipse里面F3跳来跳去，再不行还能debug。
• 开发效率。Spring这种通过XML配置的方式，很容易配置错误，影响开发效率。当然有些配置可以使用Anotation配置，但是不能完全替代XML，比如包扫描，创建多个实例都需要通过XML来配置。Spring的这种设计是一种通过XML来编程的方式。
• 测试效率。配置多的话，容器启动时间比较长，影响测试效率。所有有些测试，我们尽量都不启动Spring容器。
• 有一定的上手成本。

6 druid的优缺点

• 监控强大
• 日志打印

8 mybatis 和hibernate的对比

MyBatis在Session方面和Hibernate的Session生命周期是一致的，同样需要合理的Session管理机制。MyBatis同样具有二级缓存机制。 MyBatis可以进行详细的SQL优化设计。

• SQL优化方面 
  Hibernate的查询会将表中的所有字段查询出来，这一点会有性能消耗。Hibernate也可以自己写SQL来指定需要查询的字段，但这样就破坏了Hibernate开发的简洁性。而Mybatis的SQL是手动编写的，所以可以按需求指定查询的字段。
• 扩展性方面 
  Hibernate与具体数据库的关联只需在XML文件中配置即可，所有的HQL语句与具体使用的数据库无关，移植性很好。MyBatis项目中所有的SQL语句都是依赖所用的数据库的，所以不同数据库类型的支持不好。
• 优势对比 
  Mybatis优势 
  MyBatis可以进行更为细致的SQL优化，可以减少查询字段。 
  MyBatis容易掌握，而Hibernate门槛较高。 
  Hibernate优势 
  Hibernate的DAO层开发比MyBatis简单，Mybatis需要维护SQL和结果映射。 
  Hibernate对对象的维护和缓存要比MyBatis好，对增删改查的对象的维护要方便。 
  Hibernate数据库移植性很好，MyBatis的数据库移植性不好，不同的数据库需要写不同SQL。 
  Hibernate有更好的二级缓存机制，可以使用第三方缓存。MyBatis本身提供的缓存机制不佳。

查看hibernate和mybatis性能对比测试 
测试结果：

总体初观，myBatis在所有情况下，特别是插入与单表查询，都会微微优于hibernate。不过差异情况并不明显，可以基本忽略差异。 
差异比较大的是关联查询时，hibernate为了保证POJO的数据完整性，需要将关联的数据加载，需要额外地查询更多的数据。这里hibernate并没有提供相应的灵活性。 
关联时一个差异比较大的地方则是懒加载特性。其中hibernate可以特别地利用POJO完整性来进行缓存，可以在一级与二级缓存上保存对象，如果对单一个对象查询比较多的话，会有很明显的性能效益。 
以后关于单对象关联时，可以通过懒加载加二级缓存的方式来提升性能。 
最后，数据查询的性能与orm框架关无太大的关系，因为orm主要帮助开发人员将关系数据转化成对象型数据模型，对代码的深析上来看，hibernate设计得比较重量级，对开发来说可以算是重新开发了一个数据库，不让开发去过多关心数据库的特性，直接在hibernate基础上进行开发，执行上分为了sql生成，数据封装等过程，这里花了大量的时间。然而myBatis则比直接，主要是做关联与输出字段之间的一个映射。其中sql基本是已经写好，直接做替换则可，不需要像hibernate那样去动态生成整条sql语句。 
好在hibernate在这阶段已经优化得比较好，没有比myBatis在性能上差异太多，但是在开发效率上，可扩展性上相对myBatis来说好太多。

9. nosql 关系型数据库对比

9.1 NOSQL的优势

1易扩展

NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

2. 大数据量，高性能

NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。

3. 灵活的数据模型

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。

4. 高可用

NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。 
总结 
NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。

MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上，NoSQL关注在存储上。