MQ

ZooKeeper

​ ZooKeeper 提供基础的目录/名字服务、配置管理服务。并且在此基础上还能提供分布式锁、leader选举等高级功能。网上有一段有趣生动的介绍:“ZooKeeper，顾名思义就是动物园里大象(hadoop)、蜜蜂(Hive)、小猪(Pig)、和我的猫(MyCat)的管理员”。

​ 客户端建议采用Apache Curator这个二次封装的客户端来进行客户端代码的编写，它封装和简化了很多于业务无关的逻辑，使用简单，质量可靠。

Apache Kafka

​ Kafka是一个高吞吐量的分布式消息系统，由LinkIn开源，被描述为LinkeIn的“中枢神经系统”。Kafka管理从各个应用程序汇聚到此的信息流，这些数据经过处理后再被分发到何处。

​ Kafka使用Scala开发，而Scala又是JVM上运行的动态需要，因此对会Java的同学来说学习难度并不大，其客户端也支持Java语言，比较容易部署在本机上进行学习研究。

Facebook Thrift

​ Facebook Thrift是最新一代高性能、跨需要的RPC通信框架，支持多种语言。

​ Facebook Thrift与Ice类似，不过没有Ice完整和成熟。与Facebook Thrift类似的还有Apache Avro。

Apache Storm、Spark Streaming 、Samza

​ 与Hadoop相比Storm是个实时的高容错的分布式计算系统。Storm也可以处理批量数据，但其在保证高可靠性的前提下还可以让处理进行得更加实时，所有的信息都会被处理。Storm同样还具备容错和分布计算的特性，这让Storm可以扩展到不同的机器上进行大批量的数据处理。

Storm的主要开发语言为Java，并且包括了Clojure这种Lisp语言，对于Java工程师来说，学习难度并不大。与Strom类似的还有Spark Streaming、LinkIn的Samza，它们都是最近开源的热门项目。

​ Spark Streaming是Spark中新的流式计算框架。Spark并不会像Strom那样一次处理一个数据流，而是在处理前按时间间隔预先将其分为一段段的批处理作业。

​ 而Samza处理数据流时，会依次处理收到的每条消息。Samza的流单位既不是元组，也不是Dstream而是一条条消息。

​ Strom、Spark Streming、Samza这三种实时流计算系统都是分布式系统，具有低延迟、可扩展和容错性等诸多优点。它们的共同特同特色在于：允许你在运行数据流代码时，将任务分配到一系列具有容错能力的计算机上并行运行，此外，它们都提供了简单的API来简化底层实现的复杂程度。

互联网公司常用四大类中间件之搜索中间件与缓存中间件

  1. 搜索中间件：Solr，ELK（ElasticSearch，Logstash，Kibana）达成近实时搜索。

底层均基于Lucence。如果能考到ELK认证（当前很少人获得），高薪无悬念。

大型互联网公司项目请求响应处理：

远端通过访问Web->检索->缓存->HBase->MapReduce->HDFS

  1. 缓存中间件：

Redis缓存常用方法大家都比较清楚：

Ehcached：轻量级Java缓存框架，通过在接口服务里跑一个Ehcached，如果Ehcached有就取出，没有再去请求数据库，数据库返回并存在Ehcached中，这样就仅在一台服务器进程内。减少了Redis的繁琐步骤，缺点是，如果服务器挂了，Ehcached也挂了，因此解耦性没有Redis好。当用户访问时，快速返回结果，速度最快。

Memcached：和Ehcached很类似，2000年即存在了。在数据库MySQL中增加memcached，减少了数据库查询，MySQL内部检测该SQL是否在memcached中存在，如果不存在，则访问数据库，否则访问memcached即可。这样就将缓存放在数据库层面，来确保数据一致性。

当我们修改数据库时，需要同步更新Redis，如果中间通过消息中间件MQ提供消费，消费者可能还需更新Redis缓存。

客户端浏览器上的cookie，jwt->token缓存来自服务器的信息，比如用户名等信息。

除了浏览器上可以做缓存，我们添加Nginx也可以做缓存。我们知道，用Nginx做网关时可以提高整体性能，提升并发量；还可以用Nginx做动静分离，把服务器的一些后端数据前置到Nginx上；另外Nginx可以缓存静态文件，也可以缓存动态文件，比如Nginx内部也支持编程开发，也可以开发出来一些组件，比如resty_luacache(Lua语言实现)，shareddict（C语言实现）。

如果Nginx缓存空间不够（比如100个），app通过加锁对数据库进行操作：

如果在app上存全量热点数据（比如1000个），可以通过集群，都复制一份数据

如果各个app分别存部分缓存数据，以保证有足够空间，应该如何处理？

采用取模的方式，增加集合进行定向流量分发，最终确定那一台服务器（1%3=2）。

比如某东的item.Xd.com下的商品详情页做定向流量分发，中间还集成了其他脚本，比如Lua。同时增加Redis，Nginx客户端或Lua语言可以直接访问Redis。

如果没有任何需要后端服务计算的查询，则放在Redis里进行缓存，另外还可以增加网关层进行缓存，还可以在业务网关和流量网关进行处理。

为什么做这么多缓存？缓存一定要前置，前置的意义是尽量减少后端逻辑的执行，在前面就找到答案；越前置响应速度越快，处理的节点个数就越少，比如nginx有几十个，网关可能有几十个，app有几百个…..当项目做的足够大，高并发越来越复杂后，可能采用下面的结构：

Lvs做缓存，Nginx做流量网关，业务网关后可能有商城业务，ERP业务，DRP业务。而商城业务下面可能是一个独立的业务线，会包含N个子系统。所以可能增加多个业务网关分别连接子系统。这样ERP就必须通过商城业务网关访问商城业务的多个子系统，通过网关控制访问。