ballenlee
- 浏览: 24667 次
-
最新评论
文章列表
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重写期间还需要维护重写缓冲区，保存新写入的命令。