- 浏览: 24642 次
最新评论
文章列表
1. 基于redis+任务表的方式
https://zhuanlan.zhihu.com/p/463471700
核心思路是 insert 任务表,可以保障数据库极高的性能,insert和redis扣减库存在一个事务里,吞吐量也是比较高的
2. 快手电商库存,因为大V直播的场景是200w人抢200w库存,几乎不能限流(因为人手一份),要保证用户体验,当前方案是强依赖redis,mysql仅仅是异步更新,业务不使用
2.1 共2个缓存 1个setNx来做限制和幂等,另一个是库存redis
Q: 为什么不用lua 把两个缓存操作合并成事务?
A: lu ...
1. 延迟消息原理
broker收到消息,如果是延迟消息,就把消息集中投递到SCHEDULE_TOPIC_XXXX和对应的Queue(queueId和延迟lever匹配),在消息体中设置(真正的topic和queue),broker会有18个task,每个task绑定一个queue,消息到期后,会将消息投递到真正的topic
2. 重试队列原理
https://wuchanming.gitbooks.io/rocketmq/content/rocketmq-ding-shi-xiao-xi-he-zhong-shi-xiao-xi-ff08-shi-er-ff09. ...
拜占庭、Paxos、Raft
- 博客分类:
- 架构
https://blog.csdn.net/qq_35423154/article/details/114538503
1. CSRF https://tech.meituan.com/2018/10/11/fe-security-csrf.html
2. XSS https://tech.meituan.com/2018/09/27/fe-security.html
3. DDOS 攻击 https://www.akamai.com/zh/our-thinking/ddos
4. DNS劫持 https://zhuanlan.zhihu.com/p/86538629
lvs+nginx+动态DNS
- 博客分类:
- 架构
https://cloud.tencent.com/developer/article/1049707
一、问题域
nginx、lvs、keepalived、f5、DNS轮询,每每提到这些技术,往往讨论的是接入层的这样几个问题:
1)可用性:任何一台机器挂了,服务受不受影响
2)扩展性:能否通过增加机器,扩充系统的性能
3)反向代理+负载均衡:请求是否均匀分摊到后端的操作单元执行
二、上面那些名词都是干嘛的
1. juc相关问题
1.1 java线程池
1.2 execute 和 submit区别
1.3 CompletableFuture
1.4 synchronized 原理 https://www.jianshu.com/p/d53bf830fa09
1.5 可重入锁
1.6 阻塞队列原理、性能
1.7 线程模型
2. java基础
2.1 语法糖原理
2.2 wait notify notifyall区别
2.3 volitile原理
2.4 序列化原理
G1垃圾收集 http://www.javaadu.online/?p=465
新生代收集stw,会并发执行,通常很快(即可忽略影响)
并发周期通常会多次young gc和1次mixed gc, 并发标记的初始标记阶段,通常是在young gc阶段同时完成
jdk8 之后的jvm重要参数
metaspace ...
转自 https://juejin.im/post/5da07a066fb9a04ddf2c3e05
前言
首发自 blog.cc1234.cc/
传输控制协议(缩写:TCP)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793定义。
TCP在不可靠的IP协议之上实现了可靠性, 从而使得我们不必再去关注网络传输中的种种复杂性,所谓的可靠就是让我们去信任它即可
信任归信任,可我们还是的得去了解它,知道它为何值得信任,信任主要体现在哪些方面,换句话说就是
TCP的可靠性是什么
TCP如何实现的可靠性
上面的问题就是本文讨 ...
1. cluster模式
优点:
客户端(Jedis)直连redis节点,性能会更好
缺点:
1. 客户端(Jedis)直连redis节点,意味着客户端就需要保存集群所有节点信息,当集群比较大100-200个master节点时,这个数据量会比较大
2. 当集群规模比较大,100-200个master节点时,算上从节点,要到200-400个节点,互相ping pong的健康检查网络开销会非常大
2. proxy模式
优点:
1. 客户端(Jedis)直连有限的proxy节点,会比较轻量和简单
2. 集群规模理论上可以非常大,因为prox ...
zookeeper的缺点和分布式锁问题
- 博客分类:
- 架构
转载 http://www.chaozh.com/whats-bad-in-zookeeper-design/
转载 https://mp.weixin.qq.com/s?__biz=MzI4MTY5NTk4Ng==&mid=2247489041&idx=1&sn=b58745994c0c98662e2330c966b5036f&source=41#wechat_redirect
1. API事务能力不足,不支持客户端发起事务性的多步骤操作
2. 服务器无仲裁能力,ZK服务器端不能做基本的判断逻辑,必须都在客户端进行
提 ...
zookeeper ZAB协议
- 博客分类:
- 架构
转载自 https://www.cnblogs.com/leesf456/p/6012777.html
一、前言
在学习了Paxos在Chubby中的应用后,接下来学习Paxos在开源软件Zookeeper中的应用。
二、Zookeeper
Zookeeper是一个开源的分布式协调服务,其设计目标是将那些复杂的 ...
zookeeper 数据存储 和 写入
- 博客分类:
- 架构
参照 https://www.cnblogs.com/leesf456/p/6179118.html
可以简单概括为以下
1. 使用内存数据库,定期全量dump快照数据到硬盘
2. 针对所有的更新操作,在返回客户端“更新成功”的响应前,zookeeper会保证已经将本次更新操作的事务日 ...
zookeeper leader选举
- 博客分类:
- 架构
主要参照 https://www.cnblogs.com/leesf456/p/6107600.html
有时间还可以看下源码确认下
选举主要有两种
1. 服务启动时选举
2. 运行期选举
1. 服务启动时选举
因为服务启动时,初始状态一致(epoch)相同,所以启动阶段选举比较简单
1)各个服务器节点,广播自己的优先级标识 (sid,zxid)
2)服务器节点收到其他广播消息后,跟自己的优先级对比,自己优先级低,则变更当前节点投票的优先级(sid,zxid) ,并广播变更后的结果
3)当任意一个服务器节点收到的投票数,超过 ...
zookeeper关键字段解释
- 博客分类:
- 架构
1. zxid
zxid,也就是事务id, 为了保证事务的顺序一致性,zookeeper 采用了递增的事务 id 号(zxid)来标识事务。所有的提议(proposal)都 在被提出的时候加上了 zxid。实现中 zxid 是一个 64 位的 数字,它高32位是epoch(ZAB协议通过epoch编号来 区分 Leader 周期变化的策略)用来标识 leader 关系是否 改变,每次一个 leader 被选出来,它都会有一个新的 epoch=(原来的epoch+1),标识当前属于那个leader的 统治时期。低32位用于递增计数。
总结:实际就是写请求的的事务id,高32位表示 ...
ZooKeeper整体介绍
- 博客分类:
- 架构
https://segmentfault.com/a/1190000016349824
https://blog.csdn.net/gwd1154978352/article/details/78239633
1. ZooKeeper是什么
ZooKeeper 是一个典型的分布式数据一致性解决方案,分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
典型应用:
1)服务治理(适用于小型系统,大公司和大业务不适合)
2)配置管理(watch机制动态通知)
3)集 ...