电商网站上：

小电商：页面静态化的方案;

比如 电商平台商品详情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