随笔分类 - Redis
摘要：1、在虚拟机中安装CentOS （1）使用CentOS-6.5-i386-minimal.iso。（2）创建虚拟机：打开Virtual Box，点击“新建”按钮，点击“下一步”，输入虚拟机名称为eshop-cache01，选择操作系统为Linux，选择版本为Red Hat，分配1024MB内存，后面
阅读全文
摘要：一般的电商演变： 商品详情页系统架构演进历程 第一个版本 架构设计 J2EE+Tomcat+MySQL 动态页面，每次请求都要调用多个依赖服务的接口，从数据库里查询数据，然后通过类似JSP的技术渲染到HTML模板中，返回最终HTML页面 架构缺陷 每次请求都是要访问数据库的，性能肯定很差 每次请求都
阅读全文
摘要：相对来说，考虑的比较完善的一套方案，分为事前，事中，事后三个层次去思考怎么来应对缓存雪崩的场景 1、事前解决方案 发生缓存雪崩之前，事情之前，怎么去避免redis彻底挂掉 redis本身的高可用性，复制，主从架构，操作主节点，读写，数据同步到从节点，一旦主节点挂掉，从节点跟上 双机房部署，一套red
阅读全文
摘要：在生产环境中部署一个短路器，一开始需要将一些关键配置设置的大一些，比如timeout超时时长，线程池大小，或信号量容量 然后逐渐优化这些配置，直到在一个生产系统中运作良好 （1）一开始先不要设置timeout超时时长，默认就是1000ms，也就是1s（2）一开始也不要设置线程池大小，默认就是10（3
阅读全文
摘要：多个商品，需要发送多次网络请求，调用多次接口，才能拿到结果 可以使用HystrixCollapser将多个HystrixCommand合并到一起，多个command放在一个command里面去执行，发送一次网络请求，就拉取到多条数据 用请求合并技术，将多个请求合并起来，可以减少高并发访问下需要使用的
阅读全文
摘要：有一个概念，叫做reqeust context，请求上下文，一般来说，在一个web应用中， 我们会在一个filter里面，对每一个请求都施加一个请求上下文，就是说，tomcat容器内，每一次请求，就是一次请求上下文 在一次请求上下文中，如果有多个command，参数都是一样的，调用的接口也是一样的，
阅读全文
摘要：hystrix进行资源隔离，其实是提供了一个抽象，叫做command，就是说，你如果要把对某一个依赖服务的所有调用请求，全部隔离在同一份资源池内 对这个依赖服务的所有调用请求，全部走这个资源池内的资源，不会去用其他的资源了，这个就叫做资源隔离 hystrix最最基本的资源隔离的技术，线程池隔离技术
阅读全文
摘要：hystrix，框架，提供了高可用相关的各种各样的功能，然后确保说在hystrix的保护下，整个系统可以长期处于高可用的状态，100%。 高可用系统架构： 资源隔离、限流、熔断、降级、运维监控 资源隔离：让你的系统里，某一块东西，在故障的情况下，不会耗尽系统所有的资源，比如线程资源。 限流：高并发的
阅读全文
摘要：1、在storm中，实时的计算出瞬间出现的热点。 某个storm task，上面算出了1万个商品的访问次数，LRUMap 频率高一些，每隔5秒，去遍历一次LRUMap，将其中的访问次数进行排序，统计出往后排的95%的商品访问次数的平均值 比如说，95%的商品，访问次数的平均值是100 从最前面开始，
阅读全文
摘要：在nginx这一层，接收到访问请求的时候，就把请求的流量上报发送给kafka storm才能去消费kafka中的实时的访问日志，然后去进行缓存热数据的统计 从lua脚本直接创建一个kafka producer，发送数据到kafka lua脚本： 两台机器上都这样做，才能统一上报流量到kafka bi
阅读全文
摘要：大数据也是构建各类系统的时候一种全新的思维，以及架构理念，比如Storm，Hive，Spark，ZooKeeper，HBase，Elasticsearch，等等 storm，在做热数据这块，如果要做复杂的热数据的统计和分析，亿流量，高并发的场景下，最合适的技术就是storm，没有其他 举例说明： S
阅读全文
摘要：如果缓存服务在本地的ehcache中都读取不到数据。 这个时候就意味着，需要重新到源头的服务中去拉去数据，拉取到数据之后，赶紧先给nginx的请求返回，同时将数据写入ehcache和redis中 分布式重建缓存的并发冲突问题 重建缓存：数据在所有的缓存中都不存在了（LRU算法弄掉了），就需要重新查询
阅读全文
摘要：因为用nginx+lua去开发，所以会选择用最流行的开源方案，就是用OpenResty nginx+lua打包在一起，而且提供了包括redis客户端，mysql客户端，http客户端在内的大量的组件 1、部署第一个nginx，作为应用层nginx （1）部署openresty （2）nginx+lu
阅读全文
摘要：时效性要求很高的数据，库存，采取的是数据库+缓存双写的技术方案，也解决了双写的一致性的问题 缓存数据生产服务，监听一个消息队列，然后数据源服务（商品信息管理服务）发生了数据变更之后，就将数据变更的消息推送到消息队列中 缓存数据生产服务可以去消费到这个数据变更的消息，然后根据消息的指示提取一些参数，然
阅读全文
摘要：缓存数据生产服务的工作流程分析 （1）监听多个kafka topic，每个kafka topic对应一个服务（简化一下，监听一个kafka topic） （2）如果一个服务发生了数据变更，那么就发送一个消息到kafka topic中 （3）缓存数据生产服务监听到了消息以后，就发送请求到对应的服务中调
阅读全文
摘要：pox文件： Application： 更新数据的时候，根据数据的唯一标识，将操作路由之后，发送到一个jvm内部的队列中 读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据+更新缓存的操作，根据唯一标识路由之后，也发送同一个jvm内部的队列中 一个队列对应一个工作线程 每个工作线程串行拿到对
阅读全文
摘要：采用三级缓存：nginx本地缓存+redis分布式缓存+tomcat堆缓存的多级缓存架构 时效性要求非常高的数据：库存 一般来说，显示的库存，都是时效性要求会相对高一些，因为随着商品的不断的交易，库存会不断的变化 时效性要求不高的数据：商品的基本信息（名称、颜色、版本、规格参数，等等） 商品价格/库
阅读全文
摘要：一、节点间的内部通信机制 1、基础通信原理 （1）redis cluster节点间采取gossip协议进行通信 跟集中式不同，不是将集群元数据（节点信息，故障，等等）集中存储在某个节点上，而是互相之间不断通信，保持整个集群所有节点的数据是完整的 维护集群的元数据用得，集中式，一种叫做gossip 集
阅读全文
摘要：1、单机redis在海量数据面前的瓶颈 2、怎么才能够突破单机瓶颈，让redis支撑海量数据？ 3、redis的集群架构 redis cluster 支撑N个redis master node，每个master node都可以挂载多个slave node 读写分离的架构，对于每个master来说，写
阅读全文
摘要：一主一从，往主节点去写，在从节点去读，可以读到，主从架构就搭建成功了 1、启用复制，部署slave node 使用redis-3.2.8.tar.gz （1）redis utils目录下，有个redis_init_script脚本（2）将redis_init_script脚本拷贝到linux的/et
阅读全文
