分布式消息队列

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 关注在存储上。