- 博客(422)
- 资源 (2)
- 问答 (1)
- 收藏
- 关注
RSS订阅原创 concurrenthashmap
(sc < 0：表示当前 table，【正在扩容】，sc 高 16 位是扩容标识戳，低 16 位是线程数 + 1。b.// 设置当前线程参与到扩容任务中，将 sc 低 16 位值加 1，表示多一个线程参与扩容。我理解的，先计算前面有多少个0，然后转成进行或运算（高16位0，低16位的第一位是1），后面有反操作，如果线程完成迁移的话，则会减1，所有线程减完，等到这个戳，表示迁移完了。即高18位标记：迁移动作+容量标记，低16位，即线程数（每个线程如果要迁移，则加1）树高小于8且桶的长度小于64位，不能树化。
2023-05-15 19:54:51
549
1
原创 http自动跳转https
server {listen 80;server_name 51mll.com;rewrite ^ https://www.51mll.com$request_uri? permanent;location / {root html;index index.html index.htm;}}
2022-01-12 11:17:36
1146
原创 twemproxy + redis + sentinel 实现redis集群高可用
请参考https://www.huangdc.com/254和https://my.oschina.net/dchuang/blog/666827，讲的非常好
2021-03-03 16:38:04
322
1
原创 亿级流量电商详情页系统实战-53.nginx缓存失效解决方案
1.介绍大家还记得，我们在nginx中设置本地的缓存的时候，会给一个过期的时间，比如说10分钟。10分钟以后自动过期，过期了以后，就会重新从redis中去获取数据，这个10分钟到期自动过期的事情，就叫做缓存的失效。如果缓存失效以后，那么实际上此时，就会存在缓存失效的问题。比如说同一时间来了1000个请求，都将缓存cache在了nginx自己的本地，缓存失效的时间都设置了10分钟。那么是不是可能导致10分钟过后，这些数据，就自动全部在同一时间失效了。如果同一时间全部失效，会不会导致说同一时间大量的请求过
2021-03-03 11:19:41
354
原创 亿级流量电商详情页系统实战-52.缓存穿透解决方案
1.介绍大量访问一个不存在的值，最终造成大量请求至mysql，导致mysql压力倍增。2.解决方案使用布隆表达式如果查询不到，默认使用一个空的数据，比如说空的productInfo的json串，存于redis和ehcache中。3. 实现这里介绍第二种方案，即将空值存在缓存中。public class GetProductInfoCommand extends HystrixCommand<ProductInfo> { private Long productId;
2021-03-03 10:39:38
113
原创 亿级流量电商详情页系统实战-51.缓存雪崩解决方案
1.前言缓存雪崩这种场景，缓存架构中非常重要的一个环节，应对缓存雪崩的解决方案，避免缓存雪崩的时候，造成整个系统崩溃，带来巨大的经济损失redis集群彻底崩溃缓存服务大量对redis的请求hang住，占用资源缓存服务大量的请求打到源头服务去查询mysql，直接打死mysql源头服务因为mysql被打死也崩溃，对源服务的请求也hang住，占用资源缓存服务大量的资源全部耗费在访问redis和源服务无果，最后自己被拖死，无法提供服务nginx无法访问缓存服务，redis和源服务，只能基于本地缓存
2021-03-03 10:27:19
102
2
原创 亿级流量电商详情页系统实战-50.生产环境中的hystrix分布式系统的工程运维经验总结
如果发现了严重的依赖调用延时，先不用急着去修改配置，如果一个command被限流了，可能本来就应该限流在netflix早期的时候，经常会有人在发现短路器因为访问延时发生的时候，去热修改一些值遏制，比如线程池大小，队列大小，超时时长，等等，给更多的资源，但是这其实是不对的如果我们之前对系统进行了良好的配置，然后现在在高峰期，系统在进行线程池reject，超时，短路，那么此时我们应该集中精力去看底层根本的原因，而不是调整配置为什么在高峰期，一个10个线程的线程池，搞不定这些流量呢？？？代码..
2021-03-02 16:01:19
197
原创 亿级流量电商详情页系统实战-49.hystrix metric和dashboard
为什么需要监控与报警？HystrixCommand执行的时候，会生成一些执行耗时等方面的统计信息。这些信息对于系统的运维来说，是很有帮助的，因为我们通过这些统计信息可以看到整个系统是怎么运行的。hystrix对每个command key都会提供一份metric，而且是秒级统计粒度的。这些统计信息，无论是单独看，还是聚合起来看，都是很有用的。如果将一个请求中的多个command的统计信息拿出来单独查看，包括耗时的统计，对debug系统是很有帮助的。聚合起来的metric对于系统层面的行为来说，是很有帮.
2021-03-02 15:11:59
221
原创 亿级流量电商详情页系统实战-48.生产环境中的线程池自动扩容与缩容的动态资源分配经验
1.介绍可能会出现一种情况，比如说我们的某个依赖，在高峰期，需要耗费100个线程，但是在那个时间段，刚好其他的依赖的线程池其实就维持一两个就可以了但是，如果我们都是设置死的，每个服务就给10个线程，那就很坑，可能就导致有的服务在高峰期需要更多的资源，但是没资源了，导致很多的reject。但是其他的服务，每秒钟就易一两个请求，结果也占用了10个线程，占着茅坑不拉屎做成弹性的线程资源调度的模式刚开始的时候，每个依赖服务都是给1个线程，3个线程，但是我们允许说，如果你的某个线程池突然需要大量的
2021-03-02 14:50:12
298
原创 亿级流量电商详情页系统实战-47.生产环境中的线程池大小以及timeout超时时长优化经验总结
1.介绍生产环境里面，一个是线程池的大小怎么设置，timeout是什么时长？不合理的话，问题还是很大的。在生产环境中部署一个短路器，一开始需要将一些关键配置设置的大一些，比如timeout超时时长，线程池大小，或信号量容量。然后逐渐优化这些配置，直到在一个生产系统中运作良好。一开始先不要设置timeout超时时长，默认就是1000ms，也就是1s一开始也不要设置线程池大小，默认就是10直接部署hystrix到生产环境，如果运行的很良好，那么就让它这样运行好了让hystrix应用，24小时运行在
2021-03-02 14:31:34
181
原创 亿级流量电商详情页系统实战-46.基于facade command开发商品服务接口的手动降级机制
1.介绍可以执行主流程，command，也可以执行一个备用降级的command一般来说，都是去执行一个主流程的command，如果说你现在知道有问题了，希望能够手动降级的话，动态给服务发送个请求。在请求中修改标识位，自动就让command以后都直接过来执行备用command3个command，套在最外面的command，是用semaphore信号量做限流和资源隔离的，因为这个command不用去care timeout的问题，嵌套调用的command会自己去管理timeout超时的2.例子pu
2021-03-02 14:01:04
118
原创 亿级流量电商详情页系统实战-46.基于双层嵌套command开发商品服务接口的多级降级机制
1.介绍先降一级，尝试用一个备用方案去执行，如果备用方案失败了，再用最后下一个备用方案去执行command嵌套command尝试从备用服务器接口去拉取结果特别要注意的是，在做多级降级的时候，要将降级command的线程池单独做一个出来2.例子public class GetProductInfoCommand extends HystrixCommand<ProductInfo> { public static final HystrixCommandKey KE
2021-03-02 13:46:43
104
原创 亿级流量电商详情页系统实战-45.为商品服务接口调用增加stubbed fallback降级机制
1.介绍stubbed fallback残缺的降级用请求中的部分数据拼装成结果，然后再填充一些默认值，返回比如说你发起了一个请求，然后请求中可能本身就附带了一些信息，如果主请求失败了，走到降级逻辑。在降级逻辑里面，可以将这个请求中的数据，以及部分本地缓存有的数据拼装在一起，再给数据填充一些简单的默认值。然后尽可能将自己有的数据返回到请求方2.例子@Overrideprotected ProductInfo getFallback() { ProductInfo productInfo =
2021-03-02 11:45:19
123
原创 亿级流量电商详情页系统实战-44.hystirx的fail-fast与fail-silient两种最基础的容错模式
1.fail-fast就是不给fallback降级逻辑，HystrixCommand.run()，直接报错，直接会把这个报错抛出来，即在histrix线程中会捕获到异常，但在tomcat调用线程中不会捕获到异常。public class FailureModeCommand extends HystrixCommand<Boolean> { private boolean failure; public FailureModeCommand(boolean failure) {
2021-03-02 11:32:02
194
原创 亿级流量电商详情页系统实战-43.基于request collapser请求合并技术进一步优化批量查询
1.前言在之前，我们已经优化过一个批量查询的接口了，request cache来做优化，可能有相同的商品就可以直接取用缓存了。但现在还存在一个优化场景：多个商品，需要发送多次网络请求，调用多次接口，才能拿到结果。2.request collapser介绍可以使用HystrixCollapser将多个HystrixCommand合并到一起，多个command放在一个command里面去执行，发送一次网络请求，就拉取到多条数据用请求合并技术，将多个请求合并起来，可以减少高并发访问下需要使用的线
2021-03-02 11:12:59
147
原创 亿级流量电商详情页系统实战-42.深入分析hystrix参数
1.缓存1.1 增加HystrixRequestContextFilter/** * hystrix请求上下文过滤器 * @author Administrator * */public class HystrixRequestContextFilter implements Filter { public void init(FilterConfig config) throws ServletException { } public void doFilter(Servl
2021-03-01 15:52:59
77
原创 亿级流量电商详情页系统实战-41.深入分析hystrix执行时的8大流程步骤以及内部原理
构建一个HystrixCommand或者HystrixObservableCommand一个HystrixCommand或一个HystrixObservableCommand对象，代表了对某个依赖服务发起的一次请求或者调用构造的时候，可以在构造函数中传入任何需要的参数。(1) HystrixCommand主要用于仅仅会返回一个结果的调用。(2) HystrixObservableCommand主要用于可能会返回多条结果的调用。(3) HystrixCommand command = new H...
2021-03-01 11:31:28
89
原创 亿级流量电商详情页系统实战-40.hystrix的线程池+服务+接口划分以及资源池的容量大小控制
1.资源隔离hystrix默认的策略就是线程池，execution.isolation.strategy：指定了HystrixCommand.run()的资源隔离策略线程池隔离线程池其实最大的好处就是对于网络访问请求，如果有超时的话，可以避免调用线程阻塞住信号量隔离(1) 通常是针对超大并发量的场景下，每个服务实例每秒都几百的QPS，那么此时你用线程池的话，线程一般不会太多，可能撑不住那么高的并发，如果要撑住，可能要耗费大量的线程资源，那么就是用信号量，来进行限流保护(2) 一般用信号量常见于
2021-02-26 16:44:53
172
1
原创 亿级流量电商详情页系统实战-39.基于hystrix的信号量技术
1.线程池隔离技术与信号量隔离技术的区别2.线程池隔离技术与信号量隔离技术使用场景线程池：适合绝大多数的场景，99%的，线程池，对依赖服务的网络请求的调用和访问，timeout这种问题信号量：适合你的访问不是对外部依赖的访问，而是对内部的一些比较复杂的业务逻辑的访问。但是像这种访问，系统内部的代码，其实不涉及任何的网络请求，那么只要做信号量的普通限流就可以了，因为不需要去捕获timeout类似的问题，算法+数据结构的效率不是太高，并发量突然太高，因为这里稍微耗时一些，导致很多线程卡在这里的
2021-02-26 15:27:31
64
原创 亿级流量电商详情页系统实战-38.hystrix开发
1. 创建Hystrix对象HystrixCommand: 依赖服务每次返回单一的回应。HystrixCommand command = new HystrixCommand(arg1, arg2);HystrixCommand<ProductInfo> getProductInfoCommand = new GetProductInfoCommand(productId);HystrixObservableCommand: 若期望依赖服务返回一个 Observable, 并
2021-02-26 15:21:24
81
原创 亿级流量电商详情页系统实战-38.hystrix与高可用系统架构：资源隔离+限流+熔断+降级+运维监控
1.前言前半部分，专注在高并发这一块，缓存架构，承载高并发，在各种高并发导致的令人崩溃/异常的场景下，运行着缓存架构，高可用性，在各种系统的各个地方有乱七八糟的异常和故障的情况下，整套缓存系统还能继续健康的run着。HA，HAProxy，主备服务间的切换，这就做到了高可用性，主备实例，多冗余实例，高可用最最基础的东西。什么样的情况下，可能会导致系统的崩溃，以及系统不可用，针对各种各样的一些情况，然后我们用什么技术，去保护整个系统处于高可用的一个情况下。2.hystrix2.1 介绍提供了高可用相
2021-02-26 14:03:34
135
原创 亿级流量电商详情页系统实战-37.瞬间缓存热点解决文案
1.前言前面我们介绍了热点数据预热问题，为了解决避免新系统刚上线，或者是redis崩溃数据丢失后重启，redis中没有数据，redis冷启动，大量流量直接到数据库。现在还有个问题需要解决，对于大量瞬间请求问题，比如做一个活动。根据前面设计的文案，会到一个固安的后端nginx中，此时这个nginx压力就比较大了。2.解决思路在storm拓扑中计算出突发的访问商品(1) 通过http请求到分发层nginx 分发层nginx增加对应接口，写
2021-02-23 14:15:06
142
1
原创 亿级流量电商详情页系统实战-36.基于nginx+lua完成商品详情页访问流量实时上报kafka的开发
1.前言在nginx这一层，接收到访问请求的时候，就把请求的流量上报发送给kafka。这样的话，storm才能去消费kafka中的实时的访问日志，然后去进行缓存热数据的统计。用得技术方案非常简单，从lua脚本直接创建一个kafka producer，发送数据到kafka。2.配置2.1下载ua-resty-kafka#cd /usr/servers/lualib/resty#wget https://github.com/doujiang24/lua-resty-kafka/archive/
2021-02-18 16:33:16
179
原创 亿级流量电商详情页系统实战-35.缓存预热解决方案
1.缓存冷启动的问题新系统第一次上线，此时在缓存里可能是没有数据的系统在线上稳定运行着，但是突然间重要的redis缓存全盘崩溃了，而且不幸的是，数据全都无法找回来这二种场景，都会造成短时间内，大量请求mysql，给数据库造成很大的压力2.缓存预热提前给redis中灌入部分数据，再提供服务肯定不可能将所有数据都写入redis，因为数据量太大了，第一耗费的时间太长了，第二根本redis容纳不下所有的数据需要根据当天的具体访问情况，实时统计出访问频率较高的热数据然后将访问频率较高的热
2021-02-18 13:57:45
170
1
原创 亿级流量电商详情页系统实战-34.Storm部署
1.环境准备1.1 安装Java 71.2 Python 2.6.62.部署2.1 下载storm安装包下载apache-storm-1.1.0.tar.gz上传至解压缩# cd /usr/local# tar -zxf apache-storm-1.1.0.tar.gz# mv apache-storm-1.1.0 storm-1.1.0配置环境变量#vi ~/.bashrc export STORM_HOME=/usr/local/storm-1.1.0 e
2021-02-18 11:32:07
125
2
原创 亿级流量电商详情页系统实战-33.Storm介绍
1.Storm的集群架构Nimbus，Supervisor，ZooKeeper，Worker，Executor，Task2.Storm的核心概念Spout：数据源的一个代码组件，就是我们可以实现一个spout接口，写一个java类，在这个spout代码中，我们可以自己尝试去数据源获取数据，比如说从kafka中消费数据bolt：一个业务处理的代码组件，spout会将数据传送给bolt，各种bolt还可以串联成一个计算链条，java类实现了一个bolt接口Topology：务虚的一个概
2021-02-18 09:43:59
117
2
原创 亿级流量电商详情页系统实战-32.缓存数据生产服务中的zk分布式锁解决方案的代码实现
1.zk分布式锁的原理我们通过去创建zk的一个临时node，来模拟给一个商品id加锁zk会给你保证说，只会创建一个临时node，其他请求过来如果再要创建临时node，就会报错，NodeExistsException那么所以说，我们的所谓上锁，其实就是去创建某个product id对应的一个临时node(1) 如果临时node创建成功了，那么说明我们成功加锁了，此时就可以去执行对redis立面数据的操作(2) 如果临时node创建失败了，说明有人已经在拿到锁了，在操作reids中的数据，
2021-02-09 15:20:32
75
原创 亿级流量电商详情页系统实战-31.分布式缓存重建并发冲突问题以及zookeeper分布式锁解决方案
1.前言如果缓存服务在本地的ehcache中都读取不到数据，这个时候就意味着，需要重新到源头的服务中去拉去数据，拉取到数据之后，赶紧先给nginx的请求返回，同时将数据写入ehcache和redis中。2.缓存服务更新问题2.1 多个缓存服务实例分布式重建的并发冲突问题一般会部署多个cache实例，同一个商品，多次请求时，可能会到达不同的cache实例上，会造成生成多个缓存，上次已缓存了，还需要缓存，失去缓存的意义了。还有个问题，当拉取12:00的商品数据时，但未更新到redis，此时另外一个请求，
2021-02-09 11:07:15
89
原创 亿级流量电商详情页系统实战-31.应用层nginx缓存实现
1.分发到应用层nginx流程应用nginx的lua脚本接收到请求获取请求参数中的商品id，以及商品店铺id根据商品id和商品店铺id，在nginx本地缓存中尝试获取数据如果在nginx本地缓存中没有获取到数据，那么就到redis分布式缓存中获取数据，如果获取到了数据，还要设置到nginx本地缓存中但是这里有个问题，建议不要用nginx+lua直接去获取redis数据。因为openresty没有太好的redis cluster的支持包，所以建议是发送http请求到缓存数据生产服务，
2021-02-08 16:24:56
130
1
原创 亿级流量电商详情页系统实战-30.分发层nginx转发商品id
1.流程图2.商品分发策略流程获取请求参数，比如productId对productId进行hashhash值对应用服务器数量取模，获取到一个应用服务器利用http发送请求到应用层nginx获取响应后返回3.引入lua http lib包#cd /usr/servers/lualib/resty/ #wget https://codechina.csdn.net/mirrors/pintsized/lua-resty-http/-/tree/master/lib/resty/http
2021-02-08 10:50:34
160
3
原创 亿级流量电商详情页系统实战-31.使用nginx+lua开发hello world
1.工程化的nginx+lua项目结构hello hello.conf lua hello.lua lualib *.lua *.so2.配置nginx.conf# vi /usr/servers/nginx/conf/nginx.confworker_processes 2; error_log logs/error.log; events {
2021-02-07 14:09:23
103
1
原创 亿级流量电商详情页系统实战-30.安装nginx
1.前言因为我们要用nginx+lua去开发，所以会选择用最流行的开源方案，就是用OpenRestynginx+lua打包在一起，提供了包括redis客户端，mysql客户端，http客户端在内的大量的组件2.服务器规划服务器备注192.168.135.135分发层nginx192.168.135.132应用层nginx192.168.135.136应用层nginx3.环境准备3.1 安装系统依赖# yum install -y readl
2021-02-07 11:49:28
130
原创 亿级流量电商详情页系统实战-29.zookeeper+kafka集群的安装部署以及如何简单使用的介绍
1. zookeeper集群搭建将zookeeper-3.4.5.tar.gz上传至/usr/local#cd /usr/local#tar -zxvf zookeeper-3.4.5.tar.gz#mv zookeeper-3.4.5 zk配置zookeeper相关的环境变量#vi ~/.bashrcexport ZOOKEEPER_HOME=/usr/local/zkexport PATH=$ZOOKEEPER_HOME/bin#source ~/.bashrc配置
2021-02-05 16:54:29
88
原创 亿级流量电商详情页系统实战-28.商品详情页结构分析、缓存全量更新问题以及缓存维度化解决方案
1.前言实时性比较高的那块数据，比如说库存，销量之类的这种数据，我们采取的实时的缓存+数据库双写的技术方案，双写一致性保障的方案实时性要求不高的数据，比如说商品的基本信息，等等，我们采取的是三级缓存架构的技术方案，就是说由一个专门的数据生产的服务，去获取整个商品详情页需要的各种数据，经过处理后，将数据放入各级缓存中，每一级缓存都有自己的作用2.商品详情页分析2.1 大型电商网站中的商品详情页的数据结构分析商品的基本信息标题：【限时直降】Apple/苹果 iPhone 7 128G
2021-02-05 13:52:57
255
原创 亿级流量电商详情页系统实战-27.数据库缓存双写不一致问题分析与解决方案设计
1.问题引入缓存更新，先修改数据库，再删除缓存，如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据出现不一致。解决思路：先删除缓存，再修改数据库，如果删除缓存成功了，如果修改数据库失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致。因为读的时候缓存没有，则读数据库中旧数据，然后更新到缓存中。2.上亿流量高并发场景下，缓存不一致解决文案2.1 比较复杂的数据不一致问题分析上面的解决思路，还是有一点问题。数据发生了变更，先删除了缓存，然后去修改数据库，此时数据库数据还没有
2021-02-05 11:02:23
92
原创 亿级流量电商详情页系统实战-26.Cache Aside Pattern缓存+数据库读写模式的分析
1. cache aside pattern读的时候，先读缓存，缓存没有的话，那么就读数据库，然后取出数据后放入缓存，同时返回响应更新的时候，先删除缓存，然后再更新数据库2.为什么是删除缓存，而不是更新缓存呢？很多时候，复杂点的缓存的场景，因为缓存有的时候，不简单是数据库中直接取出来的值商品详情页的系统，修改库存，只是修改了某个表的某些字段，但是要真正把这个影响的最终的库存计算出来，可能还需要从其他表查询一些数据，然后进行一些复杂的运算，才能最终计算出。每次修改数据库的时候，都一定要
2021-02-05 10:06:30
108
原创 亿级流量电商详情页系统实战-25.亿级流量商品详情页的多级缓存架构介绍
1.前言很多人以为，有了redis缓存，就可以支持对高并发的业务场景了。其实做复杂的缓存，如支撑电商复杂的场景下的高并发的缓存，遇到的问题，非常非常之多，绝对不是说简单的访问一下redsi就可以了。2.介绍一般采用三级缓存：nginx本地缓存+redis分布式缓存+tomcat堆缓存的多级缓存架构时效性要求非常高的数据：库存一般来说，显示的库存，都是时效性要求会相对高一些，因为随着商品的不断的交易，库存会不断的变化当然，我们就希望当库存变化的时候，尽可能更快将库存显示到页面上去，而不是说等了很长
2021-02-05 09:55:13
283
2
原创 亿级流量电商详情页系统实战-24.redis阶段性总结：1T以上海量数据+10万以上QPS高并发+99.99%高可用
1.redis总结redis：持久化、复制（主从架构）、哨兵（高可用，主备切换）、redis cluster（海量数据+横向扩容+高可用/主备切换）持久化：高可用的一部分，在发生redis集群灾难的情况下（比如说部分master+slave全部死掉了），如何快速进行数据恢复，快速实现服务可用，才能实现整个系统的高可用复制：主从架构，master -> slave 复制，读写分离的架构，写master，读slave，横向扩容slave支撑更高的读吞吐，读高并发，10万，20万，30万，上百
2021-01-28 16:31:55
174
1
原创 亿级流量电商详情页系统实战-23.redis在实践中的一些常见问题以及优化思路
1.常见问题1.1 fork耗时导致高并发请求延时RDB和AOF的时候，其实会有生成RDB快照，AOF rewrite，耗费磁盘IO的过程，主进程fork子进程fork的时候，子进程是需要拷贝父进程的空间内存页表的，也是会耗费一定的时间的一般来说，如果父进程内存有1个G的数据，那么fork可能会耗费在20ms左右，如果是10G~30G，那么就会耗费20 * 10，甚至20 * 30，也就是几百毫秒的时间info stats中的latest_fork_usec，可以看到最近一次form的
2021-01-28 16:13:05
166
1
原创 亿级流量电商详情页系统实战-22.redis cluster的核心原理分析：gossip通信、jedis smart定位、主备切换
1.节点间的内部通信机制1.1 基础通信原理redis cluster节点间采取gossip协议进行通信，跟集中式不同，不是将集群元数据（节点信息，故障，等等）集中存储在某个节点上，而是互相之间不断通信，保持整个集群所有节点的数据是完整的。集中式：好处在于，元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的存储中，其他节点读取的时候立即就可以感知到；不好在于，所有的元数据的跟新压力全部集中在一个地方，可能会导致元数据的存储有压力gossip：好处在于，元数据的更新比
2021-01-28 15:54:57
90
咨询下，cachecloud现在的版本能不能使用lettuce或redssion？
2021-11-30
TA创建的收藏夹 TA关注的收藏夹
TA关注的人