互联网公司常用四大类中间件之搜索中间件与缓存中间件
1. 搜索中间件:Solr,ELK(ElasticSearch,Logstash,Kibana)达成近实时搜索。
底层均基于Lucence。如果能考到ELK认证(当前很少人获得),高薪无悬念。
大型互联网公司项目请求响应处理:
远端通过访问Web->检索->缓存->HBase->MapReduce->HDFS
2. 缓存中间件:
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就必须通过商城业务网关访问商城业务的多个子系统,通过网关控制访问。