ballenlee
- 浏览: 22525 次
-
最新评论
文章列表
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是一个开源的分布式协调服务，其设计目标是将那些复杂的 ...
参照 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）集 ...