摘要：
单机redis，能够承载的QPS大概就在上万，到几万不等 方案 读写分离，一般都是用来支撑读高并发，写请求比较少，可能请求也就一秒几千 大量的请求都是读，一秒钟二十万次 master 同步数据 slave复制，异步的 master持久化对于主从架构的安全保障 如果采用了主从架构，那个建议必须开启ma
阅读全文
posted @ 2021-11-15 11:46
公众号/架构师与哈苏
阅读(253)
推荐(0)
摘要：
string hash list set sorted set string 这是最简单的类型，就是普通的 set 和 get，做简单的 KV 缓存。 hash 这个是类似 map 的一种结构，这个一般就是可以将结构化的数据，比如一个对象（前提是这个对象没嵌套其他的对象）给缓存在 redis 里，然
阅读全文
posted @ 2021-11-12 16:20
公众号/架构师与哈苏
阅读(61)
推荐(0)
摘要：
IO多路复用程序 socket进入队列 文件事件分发器 处理器
阅读全文
posted @ 2021-11-12 15:58
公众号/架构师与哈苏
阅读(73)
推荐(0)
摘要：
(1) 性能优化杀手锏--filesystem cache os cache,操作系统的缓存 你往es里写的数据，实际上都写到了磁盘文件里面去了，磁盘文件里面的数据操作系统会自动将里面的数据缓存到os cache里面去 es的搜索引擎严重依赖于底层filesystem cache,你如果给files
阅读全文
posted @ 2021-11-12 11:32
公众号/架构师与哈苏
阅读(533)
推荐(0)
摘要：
es写数据过程 客户端选择一个node发送请求过去，这个node就是coordinating node(协调节点) coordinting node,对document进行路由，将请求转发给对应的node(有primary shard) 实际的node上的primary shard处理请求，然后将数
阅读全文
posted @ 2021-11-11 17:51
公众号/架构师与哈苏
阅读(60)
推荐(0)
摘要：
elasticsearch设计的理念就是分布式搜索引擎，底层其实还是基于lucene的。 分布式 核心思想就是在多台机器上启动多个es进程实例，组成了一个es集群。es中存储数据的基本单位是索引，比如说你现在要在es中存储一些订单数据，你就应该在es中创建一个。接着你搞一个索引，这个索引可以拆分成多
阅读全文
posted @ 2021-11-11 15:32
公众号/架构师与哈苏
阅读(155)
推荐(0)
摘要：
分布式 首先这个mq得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计一个分布式系统，参照一下kafka的设计理念，broker->topic->pratition,每个partition放一个机器，就存一部分数据。如果现在资源不够了，简单呀，给topic增加parti
阅读全文
posted @ 2021-11-11 11:06
公众号/架构师与哈苏
阅读(68)
推荐(0)
摘要：
消息积压处理办法1：临时紧急扩容 先修复consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉。新建一个topic，partition是原来的10倍，临时建立好原先10倍的queue数量。然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不
阅读全文
posted @ 2021-11-11 10:40
公众号/架构师与哈苏
阅读(366)
推荐(0)
摘要：
消费者弄丢数据 唯一可能导致消费者弄丢数据的情况，就是说，你那个消费到了这个消息，然后消费者那边自动提交了offset,让kafka以为你已经消费好了这个消息，其实你刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢咯。 这不是一样么，大家都知道kafka会自动提交offset，那么只要
阅读全文
posted @ 2021-11-10 15:40
公众号/架构师与哈苏
阅读(183)
推荐(0)
摘要：
kafka的分布式和高可用 kafka的一个基本架构：多个broker组成，一个broker是一个节点；你创建一个topic，这个topic可以划分成多个partition，每个parttition可以存在于不同的broker上面，每个partition存放一部分数据。这是天然的分布式消息队列。 实
阅读全文
posted @ 2021-11-10 09:40
公众号/架构师与哈苏
阅读(202)
推荐(0)
浙公网安备 33010602011771号