《LAMP人之去哪儿网专场》笔记

时间：2013-09-01

地点：车库咖啡(北京海淀区西大街48号海淀图书城步行街内)

主题：去哪儿网技术专场

链接：http://www.lamper.cn/party/current/

 

(一)《去哪儿网高可靠消息队列》

1、消息队列应用场景：

   （1）广播通知（如缓存通知等）；

   （2）异步操作（实时操作中把耗时的部分异步化）

   （3）数据复制（不同的系统间共享数据。一个系统更新数据库后，通知其他的数据库）

2、现有的消息队列解决方案：

ActiveMQ、RabbitMQ、Linkdin Kafca、Taobao MetaQ…

3、方案设计：

不使用二级提交或分布式等复杂的结构，使用本地处理：

消息产生后首先放到数据库里持久化，另起一个服务从数据库加载消息，消息被消费后，再从数据库里删除。

另外还有一个服务，会采用轮询的方式加载数据库里的消息，防止网络等其他问题导致某些消息没有处理。加载后的消息会发送生产者，并使用ID进行判重。

整个MQ是生产者---消费者模式。

4、优化。

   (1)线程的使用

    虽然专家们一致建议用Executors来管理线程，但是Executors的工厂方法，要么限制线程的个数，不限制队列的个数；要么不限制线程的个数，限制队列的个数。资源不可控。

所以建议谨慎使用，除非你知道你需要的是什么。

  （2）zookeeper client的实现

   A、Netflix Curator

     存在两个bug：每订阅一个主题都会起一个线程；网络间断后不会自动恢复。

   B、Apache Curator

     Netflix Curator的后续升级版本。已经修改上述bug。

   (3) JDBC Query Timeout 尽量不要使用。

每个Timer都会起一个线程，超时之后还会关掉connection。

  （4）事务和非事务之间使用连接池进行隔离。

  （5）GC。消息都是短周期对象，因此old age中不应该存在消息对象。

  （6）优化线程。

如果有来历不明的线程或者大量第三方包创建的线程，需要考虑优化。

 

(二)《Qunar前端自动化解决方案 - fekit 》

1、概述

fikit是一套去哪儿网开发的前端开发工具,已经开源：https://github.com/rinh/fekit。

2、根据文件内容生成版本号。版本号就是内容的MD5。因此，内容不变，版本号就不变。

如果使用时间戳作版本号，只能表示文件是某天发布的，不能表示文件的内容是否发生变化。

3、PPT：http://pan.baidu.com/share/link?shareid=886909941&uk=3339058908

 

(三)《去哪儿酒店高性能实时搜索技术》

1、系统核心考量（排序有先后）

   （1）信息搜索准备和全面；

   （2）报价和房态的实时准确à实时报价抓取；

   （3）高可用性à服务拆分、监控和运维；

   （4）高性能à缓存、监控和数字；

2、实现

   （1）拆分原则：功能内聚的独立业务模块。

目的在于降低成本，同时提高系统的整体可用性（故障隔离/服务隔离）；

（2）负载均衡

 A、roundrobin（轮询）

 B、userip和cookie哈希；

 C、搜索条件哈希；

3、核心组件

（1）服务化模块间通信

  A、Nginx + QunarClient

  B、RPC：dubbo等

（2）消息中间件：activeMQ

 如果消息无须持久化，这是一个很有优势的消息队列。

 MQ不传递大对象，只返回对象的key，对象本身存在memcached中。接收方根据key从memcached中获取。这样来减少消息传递的内容。

（3）用线程池隔离服务

（4）进程内缓存：

 A、LRU.(最近最少使用算法)

 B、多级策略：两级进程内缓存+memcached。业务特点决定了memcached在这里作为持久层的功能。热点数据会优先保持到一级缓存中，LRU淘汰后放入二级缓存，二级缓存淘汰后再放入memcached（借鉴Java heap的隔代管理）。

(5)构建内存缓存的基本原则：

A、关注单个缓存对象的大小；

B、要正确地使用数据类型。如Boolean使用boolean，而String类型即使是空字符串也可能占40+的字节。

C、值域固定的字符串对象常量化：String intern()或自定义String Pool.

D、要监控缓存命中率；

E、要估算总的内存开销；

F、缓存要有明确的容量限制；

G、对于LRU缓存，不同的业务线不要使用同一个LRU队列。