学习笔记

TODO未整理 golang的gc，gmp模型，context作用，channel原理，并发打印数字，slice和map原理 kafka的重平衡，高水位，顺序消费，怎么保证消息不丢失 rocketmq怎么实现事物消息 redis数据结构，zset原理，介绍cluster已经怎么保证高可用，哨兵模式介绍 mysql聚簇索引，索引优化，结合业务怎么分库分表，为啥一个表超过1000w性能会变差 压测，限流 降怎么保证服务高可用，限流熔断降级压测都要提下 监控报警这些 限流有哪些算法，以及却别要知道下 熔断策略是啥 限流：窗口计数，滑动窗口，漏桶，令牌桶 webrtc是什么技术 webrtc与不同的socket通信有什么区别 webrtc如何实现连麦、直播的 计算方式 名称 计算方式 redis http://www.redis.cn/redis_memory/ mysql select table_schema as ‘数据库’,sum(table_rows) as ‘记录数’,sum(truncate(data_length/1024/1024, 2)) as ‘数据容量(MB)’,sum(truncate(index_length/1024/1024, 2)) as ‘索引容量(MB)’from information_schema.tableswhere table_schema=‘mysql’;参考地址： https://blog.csdn.net/fdipzone/article/details/80144166

Gitbook与Docker 最近在学习k8s容器相关，了解了docker的优势，而本身对于特别在意环境的干净，之前的Gitbook不想安装原因，是因为要安装node等信息。借此机会尝试下使用docker进行安装。 1. Docker安装 这个比较简单，直接官网下载安装，无异常 2. docker-compose 编写 # 在对应的目录下创建compose的yaml文件，我放在`Workspaces/Docker/GitBook`下 services: gitbook: image: bloodstar/gitbook-builder ports: - "4000:4000" volumes: - ./gitbook:/gitbook command: gitbook build 由于我只是使用gitbook的build，不需要serve，所以端口无所谓 3.command命令修改 3.1 初始化 修改command命令为gitbook init 3.2 插件安装 修改command命令为gitbook install，这中间会存在异常，主要是网络连接github会有一定问题 3.3 编译 修改command命令为gitbook build 4. 异常处理 4.1 初始化失败 直接建README.md SUMMARY.md 两个文件后 4.2 插件安装失败 需要特殊渠道，让服务可以可以访问 5. 部署 使用nginx做代理，直接root指向Workspaces/Docker/GitBook/gitbook/_book目录 到对应的目录夹下，运行命令docker-compose up -d

Kafka 教程地址：Kafka 一、高吞吐量 顺序写 零拷贝 分段日志：Segment 预读（Read ahead）后写（Write Behind）

ClickHouse 官网：clickhouse.com 学习资料：谷粒 核心要点： MergeTree引擎 OrderBy是主键 分布式 Explain 参数配置 语法规则 多表联查（join） 面试题 1.不支持真正的delete/update操作，不支持transactions(事物) OLAP引擎一般都不支持事物，ClickHouse的定位也是分析性数据库，而不是严格的关系型数据库，加入对于事物的支持， 必然会有锁，同时分布式事物的支持，会带来更复杂的实现，其中诸多因素，都会影响写入和查询的性能。 2.不支持高并发查询，官方建议100 QPS ClickHouse是并行计算，单个查询就可以跑满多个CPU核心，而不像MySQL单个查询单线程执行。 3.需要批量写入，频繁的单条写入会带来写入问题 ClickHouse存储结构有点类LSM，每次的insert基本都会生成一个文件目录，后台线程Merge目录文件，如果频繁写入， 后台线程就会Merge不过来，产生`Too many parts`异常。建议每秒不超过一次写入，并且是Batch写入。 4.有限的SQL语法支持，JOIN语法也比较另类，暂时不支持窗口函数 5.稀疏索引的设计使得ClickHouse不适合做单行点查询

1. 历史 snowflake是由 twitter 开源的分布式 id 生成算法，采 用 Scala 语言实现，是把一个 64 位的 long 型的 id，1 个 bit 是不用的，用其中的 41 bits 作为毫秒数，用 10 bits 作为工作机器 id，12 bits 作为序列号。 小插曲：世界上没有两片相同的雪花，所以使用雪花来表示唯一 2. 算法内容 1:第一位不使用：为什么这里第一位不使用，因为对于long类型，如果第一位是1 则说明是负数 2～42:表示时间戳，最多可以表示2^41-1次方的数值，可以是毫秒级。 43～52:表示工作机器ID，最多支持2^10机器，也就是1024的机器。可以自己定义前几位为机房ID。 53～64:表示自增ID，同一毫秒如果超过2^12次方的增长量，应该算非常大的了 3. 代码实现 public class SnowFlake { private final long workerId; private final long datacenterId; private long sequence; public SnowFlake(long workerId, long datacenterId, long sequence) { // sanity check for workerId // 这儿不就检查了一下，要求就是你传递进来的机房id和机器id不能超过32，不能小于0 // 这个是二进制运算，就是 5 bit最多只能有31个数字，也就是说机器id最多只能是32以内 // 这个是一个意思，就是 5 bit最多只能有31个数字，机房id最多只能是32以内 long maxWorkerId = ~(-1L << workerIdBits); if (workerId > maxWorkerId || workerId < 0) { throw new IllegalArgumentException( String....