- 浏览: 24892 次
最新评论
文章列表
https://mp.weixin.qq.com/s/zxPz_aFEMrshApZQ727h4g 《kafka系统设计》
https://gitbook.cn/books/5ae1e77197c22f130e67ec4e/index.html 《kafka架构》
1. 重要概念和原理
1)producer (采用推模式)和 consumer(采用拉模式,拉模式可以更灵活的控制消费速率 ...
亿级流量网站架构核心技术-高并发
- 博客分类:
- 架构
9. 应用级缓存
NULL Cache Object, 防止对象不存在,穿透访问db
缓存与db更新策略:
Cache Aside:同一个数据写竞争比较激烈,对数据一致性要求很高时适合,(写db成功后删除cache)
其他方式:根据业务场景灵活处 ...
亿级流量网站架构核心技术-高可用
- 博客分类:
- 架构
1. 交易型系统的一些设计原则
无状态:有利于水平扩容
数据异构:比如订单系统,既需要根据userId维度查询所有订单,又需要根据订单id查询,这时候需要数据异构存储
防重设计:跟客户端(比如clientSeqId)配合,或者服务 ...
《深入剖析Linux IO原理和几种零拷贝机制的实现》https://juejin.im/post/5d84bd1f6fb9a06b2d780df7#heading-24
以下是kafka常用命令行总结:
1.查看topic的详细信息
./kafka-topics.sh -zookeeper 127.0.0.1:2181 -describe -topic testKJ1
2、为topic增加副本
./kafka-reassign-partitions.sh -zook
http://lxw1234.com/archives/2016/09/719.html
这一篇讲的不错
Rowkey设计
rowkey是HBase实现分布式的基础,HBase通过rowkey范围划分不同的region,分布式系统的基本要求就是在任何时候,系统的 访问都不要出现明显的热点现象,所以rowkey的设计至关重要,一般我们建议rowkey的开始部分以hash或者MD5进行散列,尽量做到 rowkey的头部是均匀分布的。禁止采用时间、用户id等明显有分段现象的标志直接当作rowkey来使用。
列簇设计
HBase的表设计时,根据不同需求有不同选择,需要做在线查询的数据表,尽量 ...
linux 设置 ulimit
- 博客分类:
- 操作系统
java.lang.OutOfMemoryError: unable to create new native thread
启动服务报错,无法创建native thread,排查结论是被系统限制资源,设置 ulimit
root 修改 /etc/security/limits.conf
* - core 536870912
* - data unlimited
* - fsize ...
Probobuf 原理介绍
- 博客分类:
- RPC
主要参考博文《https://www.jianshu.com/p/ec39f79c0412》
主要优点:
1. 序列化速度快,压缩体积小
1.1 数据紧凑,使用 tag+value 方式,tag为字段编号
1.2 剔除无效字段,未设置字段不会传输(proto3 之后全部字段都是optional)
1.3 传输字段采用特殊规则编码,体积更小(varints & zigzag)
1.4 由于序列格式是很归整,反序列化速度非常快(基本通过位移操作即可)
2. 兼容,向后兼容,向前兼容
老的协议发给新的,新的会使用默认值
新的写 ...
Redis 缓存问题及解决方案
- 博客分类:
- Redis
1. 缓存穿透
指查询一个不存在的对象,缓存层和存储层都不会命中,可以采用缓存空对象或者bloom filter解决,两者的解决典型场景不同,bloom filter适用于数据相对固定实时性低的场景。
2. 无底洞优化
无底洞问题指水平扩展,性能没有提升甚至会下降,这是因为客户端一次批量操作会涉及很多网络操作,随着节点增多,耗时会变大,网络节点多对节点性能也有影响。优化方式是减少io,一个是使用hash_tag把mget的key放在一个节点,另一个方式是客户端根据key,slot,node 对应关系进行归类批量访问同一个node的数据。
3. 缓存雪崩
指缓 ...
Redis Cluster集群故障转移
- 博客分类:
- Redis
1. 故障发现
1.1 主观下线,Redis集群通过Gossip的ping,pong消息来互相通信,比如A节点向B节点发送ping,如果在 cluster-node-timeout时间内一直失败,则节点A会认为B是主观下线,同时将此状态信息在集群内广播
1.2 客观下线,当半数以上的持有槽的主节点都标记B是主观下线时,触发客观下线流程。
1.2.1 通知集群内所有节点,标记B为客观下线并立刻生效
1.2.2 通知故障节点的从节点触发故障转移
2. 故障恢复
客观下线后,如果故障节点是持有槽的主节点,需要从它的从节点中 ...
Redis Cluster集群水平扩展
- 博客分类:
- Redis
Redis分布式方案一般有两种
(1)客户端分区,优点是分区逻辑可控,缺点是需要客户端处理数据路由、高可用、故障转移等。
(2)代理方案,优点是简化客户端逻辑和升级,缺点是加重架构复杂性和性能损耗。
Redis Cluster是 ...
Redis Sentinel
- 博客分类:
- Redis
Redis Sentinel 是 redis的高可用实现方案:故障发现、故障自动转移、配置中心、客户端通知,Jedis原生支持,客户端在连接时,实际连接的Sentinel集合,当Sentinel观测到变化和故障转移后,会Pub到client端,实际使用了redis的pub/sub功能。
参考自
https://cloud.tencent.com/developer/article/1021467
采用了Raft算法,和ZAB类似,都是简化版的Paxos实现
前提:
1. 默认情况下,sentinel都是Follower状态
2. 当Follower判断某个mas ...
Redis 主从复制
- 博客分类:
- Redis
Redis主从复制过程,由从节点发起复制请求,默认情况从节点是只读的
1. 从节点发起复制请求,保存主节点信息
2. 主从建立socket连接
3. 从节点发送ping命令
4. 主节点权限验证(默认关闭)
5. 同步数据
6. 持续复制
其中同步数据又分为全量复制和部分复制
全量复制,从节点第一次复制必须为全量复制,全量复制过程为从节点发起,主节点保持RDB文件,主节点发送RDB文件,主节点把期间增量的命令缓存并且在RDB传输完成后发送增量命令给从节点,从节点如果开启了AOF则同步后会马上进行首次AOF。
可以看到全量复制是一个非常耗时和消耗网络带宽的操作,通 ...
Redis持久化有两种方式,RDB和AOF,持久化通常都会fork一个子进程做备份。
RDB使用一次性生成内存快照方式,压缩且文件更紧凑,读取RDB恢复速度快;但是每次RDB是全量备份,速度慢,无法做到实时持久化,通常用于数据冷备和复制传输。
AOF通过追加命令到文件实现实时(秒级)持久化,极端情况丢失2s的数据;因为不断追加命令,文件会越来越大,要定期执行重写AOF文件降低文件体积(因为老文件里的好多key可能过期或被删了),AOF重写期间还需要维护重写缓冲区,保存新写入的命令。