近来的EIP需求接入了新的数据组件，StarRocks，趁着有时间了解一下。

简单看了一下，这个数据存储在数据分析上有长处，在建表的时候就可以直接指定数据模型的类型，来确定数据入表的时候是直接保存，还是做聚合，还是做更新，还是直接主键索引。语言方便就兼容原生SQL。这个主键模型的数更新逻辑是删掉旧的，再插入新的（笑了）

说实话不少东西也看不懂究竟有什么用

可以建一个表结构联合所建立的表及案例联系。

我还是没太看懂，直接看DML相关的内容罢，先把增删改查之类的东西学完

GROUP BY 可以直接把多个要分组的内容放在一起，不怕出问题，一个句子顶上好几句的内容（GROUPING SETS）

感觉看了半天没什么印象，等之后实际使用的时候再看看怎么搞吧

消息队列：低持久性消息、较小消息可选redis,海量持久性消息选kafka,中等需求可选rebbitmq

redis适合做很小规模，业务简单的消息队列场景。

消息队列 异步，微服务 流量削峰填谷(先全塞到队列里，再慢慢处理) 消息分发（直接让应用监听消息对应的队列即可）

因为redis是直接存储内容在内存里面的，所以如果设备被断电，内容会直接清空，不是持久保存的

缺点：系统可用性降低，系统的复杂性也提高，一致性问题，没法判断对面到底有没有正确消费内容。

Redis可以做数据库，缓存和消息队列

NoSQL 非关系型数据库 方便扩展，数据量大性能高，多样
存储形式，键值对，文档，列簇，图关系等

缓存雪崩 大量key失效，访问数据库请求太多崩了
缓存穿透：缓存和数据库里面都没有的数据，所有请求都落到了数据库上，造成了数据库短时间内承受了大量的请求崩掉
缓存击穿：缓存中没有但是数据库中有并发太多又跑去数据库里面去查了，数据库撑不住 加互斥锁可以解决，没有过期时间的缓存是不推荐的

Redis主要就是基于内存，所以相应的速度很快。是不是存在一个命中率的问题，命中就直接取读缓存，没命中就去读数据库，同时回写缓存