电商网站上：
小电商：页面静态化的方案;
比如 电商平台商品详情API接口商品的信息放到表中 + 页面模板，渲染成html页面，每次用户请求的时候，直接返回html页面，不涉及到业务逻辑。
缺点一旦模板发生了变更，所有的Html页面需要重新渲染，小网站还ok,大网站不可。
大型电商网站：商品详情页
多级缓存+双层nginx提高命中率+热点数据自动降级+缓存维度化
==>多级(三级)缓存每一级的意义
① nginx分发层，根据productId的hash取模，将流量分发到应用层nginx，nginx本地缓存扛热点数据，如果缓存仅仅放在redis，则多N次的网络开销。
② redis扛大量的离散数据。(单机的redis的QPS大概到几W)
③ ehcache扛redis集群大规模灾难，避免Mysql裸奔。
==>缓存多维度
将实时性要求比较高的信息(库存|销量等) 和 实时性要求不高的信息 分开存储。
其中实时性不高的信息 (商品信息，分类信息，店铺信息)也 分key-value缓存。
实时性要求比较高的信息，采用数据库+mysql同步双写。实时性要求不高的信息，采用异步写缓存。
这样做的好处：
① redis的性能和吞吐量：数据越大，吞吐量急剧下降
② 降低更新缓存的频率
==>双层nginx提高缓存命中率
假设仅仅有第二层缓存，一个请求过来随机打到不同的nginx上，同一个productId而言，第一次打到一台nginx机器上，本地加载了缓存，第二次过来请求打到了不同的nginx机器上，查看nginx本地缓存无。
双层nginx缓存，请求统统到分发层nginx，根据分发策略(比如productId的hash取模)，这样，对于同一个productId请求会打到同一个应用层nginx。
应用层nginx相当于网管层gateway。
==>热点数据自动降级
① nginx+lua将访问流量上报到kafaka
② storm从kafka中消费数据，实时统计出每个商品的访问次数，访问次数基于LRU内存数据结构的存储方案
热点：某个商品的访问量，瞬间超出了普通商品访问量的10倍，或者100倍，1000倍。
③ 热点一旦统计出来，storm会直接发送http请求到nginx上，nginx如果发现某个商品是热点数据，就立即做流量分发策略的降级。
在所有的应用层nginx本次缓存上加载热点数据，同时对该商品的分发策略，从hash取模修改成随机，分发到不同的nginx应用层，来分发流量。
java和大数据的关系:
storm和spark的区别
对于strom来说
1.纯实时(毫秒级)，不能忍受1秒以上延迟
2.支持事务
3.高峰低峰时间段，动态调整实时计算程序
4.纯实时，不需要在中间执行SQL交互式查询
对于spark streaming来说
1.准实时(秒级),不要求强大可靠的事务机制，不要求动态调整并行度
2.如果一个项目除了实时计算之外，还包含了离线批处理，交互式查询等业务功能，而且实时计算中，可能还牵扯到 高延迟批处理，交互式查询等功能，那么首选Spark生态，用Spark Core开发离线批处理，用Spark Sql开发交互式查询，用Spark Streaming开发实时计算，三者无缝整合。
总之，Spark Streaming有一点是Storm绝对比不上的，他位于Sparking生态技术栈中，因此Spark Streaming和Spark Core，Spark SQL无缝整合，也就是意味着，可以对实时处理出来的中间数据，立即在程序中无缝进行延迟批处理，交互式查询等操作。
Storm在实时延迟上，比Spark Streaming厉害。
hive和hbase的区别
hive中的表是纯逻辑表，只是定义了表定义，本身不存储数据，完全依赖HDFS和MapReduce。将结构化的数据文件映射为一张数据表，并提供了HQL查询功能，并将HQL最终转换为MapReduce任务进行运行。不适用于实时查询，因为耗时比较严重。
HBase是物理表。海量数据的在线储存和简单查询，替代MySQL分库分表，提供更好的伸缩性。非常适合用来进行大数据的实时查询。
Storm的集群架构和核心概念
Storm的集群架构
nimbus -> supervior -> worker -> executor -> task
物理架构如下：
Storm的核心概念
Topology; spout; Bolt; Tuple; Stream
Spout：数据源的一个代码组件，实现了一个Spout接口，写一个java类，在这个spout代码中，我们可以自己尝试去数据源获取数据，比如从kafka中消费数据。
bolt: 一个业务处理的代码组件，spout会将数据传送给bolt，实现了一个bolt接口。
topology: 流程图 一堆spout+bolt，就会组成一个topology,就是一个拓扑，实时计算作业，spout+bolt，一个拓扑涵盖了数据获取/生成+数据处理的所有代码逻辑，topology。
tuple：就是一条数据，每条数据都会被封装成tuple中，在多个spout和bolt之间传递；
stream: 就是一个流，源源不断过来的tuple，组成了一个流。
构建集群如下：
构建一主两从的结构，分配三台机器
114:nimbus节点 115:supervisor节点 116:supervisor节点
配置文件中可以指定supervisor的端口(即工作进程worker的端口号)
nimbus的114机器下面可以看到 nimbus.log access.log metric.log的日志
supervisor的115机器下面可以看到 supervisor.log access.log metric.log的日志
在主节点开启管控台 storm ui &; jps查看进程
如何执行word count的代码示例：
将topology代码打成jar包，提交到nimubs节点，
执行 storm jar [jar名称] [main方法的类]
一旦开始执行以后，在supervisor节点jps命令可以看到多了个worker进程。
并行策略设定
worker=2
spout=2
bout1=2, numberTask=4
bout2=4
在物理节点supervisor上的分配如下：
redis持久化: RDB, AOF
RDB: 定时生成全量快照，作为冷备。redis主进程，去fork一个子进程，去执行RDB操作。
生成多个文件，每个文件都代表了某一个时刻的完整的数据快照。
AOF: 存放的是指令日志，做数据恢复的时候，其实是回放和执行所有的指令日志。而RDB是将数据直接加载到内存中。AOF速度比RDB略慢。但是可以更好的保证数据不丢失。
redis读写分离
写请求:1秒几千
大量的都是读请求
假如单个的redis能够承受的读是 5W QPS,如果流量上升，多搞几个slave的redis，分散读请求。水平扩容。
redis replication 基本原理
当slave刚启动的时候，会发一条ping数据给master，master会发 full resynchronization(全量复制)。
master在后台搞一个线程，把全量的快照文件发给slave。
正常情况来一条数据复制到一条数据到slave,如果异常什么的，就生成rdb快照。
哨兵
集群监控： 负责监控redis master和slave进程是否正常工作
消息中心： 如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知管理员。
故障转移： 如果Master node 挂掉，会自动转移到slave node上
哨兵本身也是分布式的，至少三个实例保证自己的健壮性
判断一个master node是否宕机了，需要大部分的哨兵都同意才行，涉及到选举问题。
脑裂问题
master主节点，出现了异常性，哨兵检测不到，故障转移，让原来的slave节点成为了master节点。于是就出现了两个主节点，大脑一分为二。
当redis会在数据达到一定的程度之后，清理掉一些数据LRU。
redis默认情况下就是使用LRU策略，最近最少使用的数据干掉。
可以在redis.conf中 设置 maxmemory
