声明：所有文章只作为学习笔记用，转载非原创
https://blog.csdn.net/qinglianchen0851/article/details/84306448
Scale Up和Scale Out的区别bai：
Scale Out是指Application可以du在水平方向上扩展。一般对zhi数据中心的应用dao而言，Scale out指的是当添加更多的机器时，应用仍然可以很好的利用这些机器的资源来提升自己的效率从而达到很好的扩展性。
Scale Up是指Application可以在垂直方向上扩展。一般对单台机器而言，Scale Up值得是当某个计算节点（机器）添加更多的CPU Cores，存储设备，使用更大的内存时，应用可以很充分的利用这些资源来提升自己的效率从而达到很好的扩展性。
http 一个连接占用多少内存 ----- 重点
https://zhuanlan.zhihu.com/p/25241630
c10m c10k 问题 ----重点关注
[http://www.52im.net/thread-561-1-1.html
redis 基础配置
https://blog.csdn.net/suprezheng/article/details/90679790
https://blog.csdn.net/weixin_40245787/article/details/87858380
镜像
http://www.linuxcoming.com/blog/2019/03/19/list_and_extract_initramfs_image.html
stress stress-ng
https://blog.csdn.net/weixin_42414349/article/details/101055361
高并发下的思考
https://www.cnblogs.com/68xi/p/10014933.html
https://www.cnblogs.com/kumufengchun/p/11065413.html tps&qps
TPS（Transactions Per Second）
中文翻译“每秒事务处理量”，即服务器每秒处理的事务数。TPS 中的 T 包含 「消息接收」、「消息处理（例如：数据库操作）」、「响应」 三个步骤，即一个完整事务。
QPS（Query Per Second）
是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。
RT（Response Time）
事务从请求到系统处理完成后返回结果的时间，即响应时间。
举个例子来理解下上述几个概念。
假设每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
每天300w PV 的在单台机器上，这台机器需要多少QPS？
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
如果一台机器的QPS是58，需要几台机器来支持？
139 / 58 = 3
https://blog.csdn.net/ZYC88888/article/details/79993243
重点Linux下如何查看高CPU占用率线程 LINUX CPU利用率计算
最佳线程数量=（（线程等待时间+线程cpu时间）/线程cpu时间）* cpu数量
https://blog.csdn.net/qq_36449541/article/details/79493605 ---
抓包分析
http 1.0 1.1 2.0
https://www.cnblogs.com/heluan/p/8620312.html
https://www.zhihu.com/question/34074946
https://www.cnblogs.com/lv-lxz/p/10974458.html
https://www.cnblogs.com/horanly/p/8675918.html
nginx 反爬虫 https://mp.weixin.qq.com/s/Y25_TRrKmVlTMvPrQja_cg https://www.jianshu.com/p/c5cf6a1967d1
https://www.jianshu.com/p/78430db6c2cd
cookie
https://www.cnblogs.com/wxinyu/p/8005621.html
https://blog.csdn.net/donglynn/article/details/54971815?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase
一、抓包中请求组成：请求行、请求头、空行、请求体
1.请求行：请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。比如 GET /data/info.html HTTP/1.1。（按我理解，就是请求信息的第一行）
2.请求头：HTTP客户程序(例如浏览器)，向服务器发送请求的时候必须指明请求类型(一般是GET或者 POST)。如有必要，客户程序还可以选择发送其他的请求头。大多数请求头并不是必需的，但Content-Length除外。对于POST请求来说 Content-Length必须出现。（按我理解，就是请求的各种信息）
3. 空行不怎么看的出来：它的作用是通过一个空行，告诉服务器请求头部到此为止。（按我理解，可以忽略不计）
4.请求体：浏览器真正发送给服务器的数据。（按我理解是需要提交的参数）
若方法字段是GET，则此项为空，没有数据
若方法字段是POST,则通常来说此处放置的就是要提交的数据
深入理解幂等性
https://www.cnblogs.com/WYPDF/p/10653089.html
一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
缓存击穿 和穿透
Redis 多级缓存架构和数据库与缓存双写不一致问题
https://www.cnblogs.com/sunliyuan/p/11336014.html
28法则，黄金法则，20%的数据，占用了80%的访问量
https://zhuanlan.zhihu.com/p/106916507
https://www.jianshu.com/p/d00348a9eb3b
https://www.cnblogs.com/sunliyuan/p/11336014.html
https://blog.csdn.net/u011277123/article/details/88757861
https://blog.csdn.net/timerbin/article/details/88430656 https://www.cnblogs.com/sunliyuan/p/11336014.html
https://blog.csdn.net/lifetragedy/article/details/103945885?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase
这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。
apache 、webshpere 中的虚拟机 集成IHS
https://www.cnblogs.com/hzk001/p/11748204.html
http://www.srcmini.com/56593.html
https://blog.csdn.net/zhaonjtu/article/details/83490323?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase
ihs:ibm http server
ihs plugin:ibm http server
关于ihs和plugin的一些知识
ihs就是一个以apache为基础的web服务器，由于其出色的静态页面处理。
https://www.cnblogs.com/tudachui/p/9485383.html
https://zhidao.baidu.com/question/401231310.html
IHS中有个IBM提供的bai插件，它会访问一个plugin-cfg.xml来获知转du发到哪些主机、端口等等，这个plugin-cfg.xml在WAS里能生成，生成后在IHS里指明该文件的位置，让IHS能读就万事大吉了。
权重是plugin-cfg.xml中设置的一个属性，好像是在ClusteredServers一节里设置的，具体的这个XML你一看便知。也可以在WAS集群里配好生成即可。
full gc 参考
https://segmentfault.com/q/1010000012356302
https://blog.csdn.net/u010739551/article/details/80620342
https://blog.csdn.net/swpihchj/article/details/8197204
jmap jstat 分析 还需要一些第三方工具生成dump文件后分析
S0C：年轻代中第一个survivor（幸存区）的容量 (字节)
S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
EC：年轻代中Eden（伊甸园）的容量 (字节)
EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)
OC：Old代的容量 (字节)
OU：Old代目前已使用空间 (字节)
PC：Perm(持久代)的容量 (字节)
PU：Perm(持久代)目前已使用空间 (字节)
YGC：从应用程序启动到采样时年轻代中gc次数
YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)
FGC：从应用程序启动到采样时old代(全gc)gc次数
FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT：从应用程序启动到采样时gc用的总时间(s)
NGCMN：年轻代(young)中初始化(最小)的大小 (字节)
NGCMX：年轻代(young)的最大容量 (字节)
NGC：年轻代(young)中当前的容量 (字节)
OGCMN：old代中初始化(最小)的大小 (字节)
OGCMX：old代的最大容量 (字节)
OGC：old代当前新生成的容量 (字节)
PGCMN：perm代中初始化(最小)的大小 (字节)
PGCMX：perm代的最大容量 (字节)
PGC：perm代当前新生成的容量 (字节)
S0：年轻代中第一个survivor（幸存区）已使用的占当前容量百分比
S1：年轻代中第二个survivor（幸存区）已使用的占当前容量百分比
E：年轻代中Eden（伊甸园）已使用的占当前容量百分比
O：old代已使用的占当前容量百分比
P：perm代已使用的占当前容量百分比
S0CMX：年轻代中第一个survivor（幸存区）的最大容量 (字节)
S1CMX ：年轻代中第二个survivor（幸存区）的最大容量 (字节)
ECMX：年轻代中Eden（伊甸园）的最大容量 (字节)
DSS：当前需要survivor（幸存区）的容量 (字节)（Eden区已满）
TT： 持有次数限制
MTT ： 最大持有次数限制
tomcat 数据源配置
https://www.cnblogs.com/ITtangtang/archive/2012/05/21/2511749.html
https://blog.csdn.net/rl_leee/article/details/79264413
https://www.sohu.com/a/333577915_120104204
https://www.cnblogs.com/ITtangtang/archive/2012/05/21/2511749.html
Engine、Host和Context都是容器，但它们不是平行的关系，而是父子关系：Engine包含Host，Host包含Context。
https://blog.csdn.net/m0_37327416/article/details/76184920
消息中间件
kafka rabbitmq rocketmq
https://www.cnblogs.com/toutou/p/linux_install_kafka.html
https://www.jianshu.com/p/014af2b34159
#内部原理
https://zhuanlan.zhihu.com/p/21262642?refer=bittiger
#消费案例 -----分享一些 Kafka 消费数据的小经验
本文将借助我使用 Kakfa 消费数据的经验来聊聊如何高效的消费数据。
http://itindex.net/detail/58979-%E5%88%86%E4%BA%AB-kafka-%E6%B6%88%E8%B4%B9
在多线程之前不得不将消费模式分为两种进行探讨：消费组、独立消费者。
消费组模式应当是使用最多的一种消费方式。
我们可以创建 N 个消费者实例（ new KafkaConsumer()）,当这些实例都用同一个 group.id 来创建时，他们就属于同一个消费组。
案例：
某个 Topic 有四个分区 p0 p1 p2 p3，同时创建了两个消费组 groupA，groupB。
A 消费组中有两个消费实例 C1、C2。
B 消费组中有四个消费实例 C3、C4、C5、C6。
这样消息是如何划分到每个消费实例的呢？
通过图中可以得知：
A 组中的 C1 消费了 P0 和 P3 分区；C2 消费 P1、P2 分区。
B 组有四个实例，所以每个实例消费一个分区；也就是消费实例和分区是一一对应的。
# 版本名
kafka_2.10-0.8.2.jar，2.10是指Scala版本，0.8.2是指kafka版本。
https://blog.csdn.net/zwgdft/article/details/54633105 很好的基础概念还有rabbitmq讲解
Topic，是Kafka下消息的类别，类似于RabbitMQ中的Exchange的概念。这是逻辑上的概念，用来区分、隔离不同的消息数据，屏蔽了底层复杂的存储方式。对于大多数人来说，在开发的时候只需要关注数据写入到了哪个topic、从哪个topic取出数据。
Partition，是Kafka下数据存储的基本单元，这个是物理上的概念。同一个topic的数据，会被分散的存储到多个partition中，这些partition可以在同一台机器上，也可以是在多台机器上，比如下图所示的topic就有4个partition，分散在两台机器上。
Consumer Group，同样是逻辑上的概念，是Kafka实现单播和广播两种消息模型的手段。group内的worker可以使用多线程或多进程来实现，也可以将进程分散在多台机器上，worker的数量通常不超过partition的数量，且二者最好保持整数倍关系，因为Kafka在设计时假定了一个partition只能被一个worker消费（同一group内）
kafka是一个分布式消息队列。具有高性能、持久化、多副本备份、横向扩展能力。
Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。
JNDI，没错 Zookeeper 的 Name Service 与 JNDI 能够完成的功能是差不多的， 它们都是将有层次的目录结构关联到一定资源上
基础知识
遵循AMQP(Advanced Message Queuing Protocol)协议
#什么是消息队列（Message Queue）？
1 消息(Message)
网络中的两台计算机或者两个通讯设备之间传递的数据。例如说：文本、音乐、视频等内容。
2 队列(Queue)
一种特殊的线性表（数据元素首尾相接），特殊之处在于只允许在首部删除元素和在尾部追加元素。入队、出队。
3 消息队列(MQ)
消息+队列，保存消息的队列。消息的传输过程中的容器；主要提供生产、消费接口供外部调用做数据的存储和获取。
#MQ主要分为两类：点对点(p2p)、发布订阅(Pub/Sub)
1 共同点：
消息生产者生产消息发送到queue中，然后消息消费者从queue中读取并且消费消息。
2 不同点：
p2p模型包括：消息队列(Queue)、发送者(Sender)、接收者(Receiver)
一个生产者生产的消息只有一个消费者(Consumer)(即一旦被消费，消息就不在消息队列中)。比如说打电话。
Pub/Sub包含：消息队列(Queue)、主题(Topic)、发布者(Publisher)、订阅者(Subscriber)。每个消息可以有多个消费者，彼此互不影响。比如我发布一个微博：关注我的人都能够看到。
#单机配置kafka
#集群搭建https://www.cnblogs.com/caoweixiong/p/11060533.html
wget http://mirrors.hust.edu.cn/apache/kafka/2.5.0/kafka_2.12-2.5.0.tgz
https://www.cnblogs.com/qpf1/p/9161742.html #部署
#zk 命令行使用
https://www.cnblogs.com/sunddenly/p/4031881.html
https://www.cnblogs.com/yako/p/9660704.html
https://blog.csdn.net/dreamzuora/article/details/79617991
https://www.cnblogs.com/farmersun/p/12758548.html
#注意配置文件
zookeeper 日志 https://www.cnblogs.com/jxwch/p/6526271.html
server.properties
kafka 依赖于zookeeper , 单机先利用kafka自带的zookeeper
tar -xvf kafka_2.12-2.5.0.tgz -C /usr/local/
#zookeeper.properties配置文件
nohup ../bin/zookeeper-server-start.sh ../config/zookeeper.properties > zookeeper-run.log 2>&1 &
#config/server.properties配置文件
nohup ../bin/kafka-server-start.sh ../config/server.properties > kafka-run.log 2>&1 &
#由于本机内存太小 修改了启动脚本中的参数
简单的参数配置
https://blog.csdn.net/u013063153/article/details/73826403
-Xmx Java Heap最大值，默认值为物理内存的1/4，最佳设值应该视物理内存大小及计算机内其他内存开销而定；
-Xms java Heap初始值，Server端JVM最好将-Xms和-Xmx设为相同值，开发测试机JVM可以保留默认值；
-Xmn Java Heap Young区大小，不熟悉最好保留默认值；
-Xss 每个线程的Stack大小，不熟悉最好保留默认值；
#创建topic
./kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic demo
#列出topic
./kafka-topics.sh --list --zookeeper localhost:2181
## 重点理解
基础概念
进阶 : https://blog.csdn.net/qq_26803795/article/details/105562691
Kafka文件存储机制 https://blog.csdn.net/u013256816/article/details/71091774
https://www.cnblogs.com/answerThe/p/11267454.html
https://blog.csdn.net/qq_26803795/article/details/105489068
https://baijiahao.baidu.com/s?id=1648598858792754188&wfr=spider&for=pc
zk 的作用
https://blog.csdn.net/peter_changyb/article/details/81562855
https://www.jianshu.com/p/64548ef611d6 #图片特别好，包括zk存储的目录结构和
消费者与群组
https://www.jianshu.com/p/619ceb9ae489
https://www.cnblogs.com/hmy-blog/p/9012507.html #组内分配策略
kafka的原理图
https://www.jianshu.com/p/da62e853c1ea
https://www.cnblogs.com/luoahong/articles/9712996.html #分区和副本
https://www.cnblogs.com/htfhxx/p/8017356.html #分区的切换
每个分区都有自己的主副本和从副本
主副本： leader 从副本： follower
同步状态的副本叫 ISR in sync replicas
从副本从主副本拉取数据
读写 都是与leader 交流，不和follower交互
1、Broker——Kafka集群包含一个或多个物理服务器，这种服务器被称为broker
假设这里只有一个Kafka集群，且这个集群只有一个Kafka broker，即只有一台物理机。
2、partition
Kafka中消息是以topic进行分类的，生产者通过topic向Kafka broker发送消息，消费者通过topic读取数据。然而topic在物理层面又能以partition为分组，一个topic可以分成若干个partition，那么topic以及partition又是怎么存储的呢?
3、segment
partition还可以细分为segment，一个partition物理上由多个segment组成，那么这些segment又是什么呢?下面我们来一一揭晓。
为了便于说明问题，假设这里只有一个Kafka集群，且这个集群只有一个Kafka broker，即只有一台物理机。
在这个Kafka broker中配置($KAFKA_HOME/config/server.properties中)log.dirs=/tmp/kafka-logs，以此来设置Kafka消息文件存储目录，
以此来设置Kafka消息文件存储目录，与此同时创建一个topic：topic_zzh_test，partition的数量为4
$KAFKA_HOME/bin/kafka-topics.sh –create –zookeeper localhost:2181 –partitions 4 –topic topic_vms_test –replication-factor 4
那么我们此时可以在/tmp/kafka-logs目录中可以看到生成了4个目录
同一个topic下有多个不同的partition，每个partiton为一个目录，partition的名称规则为：topic名称+有序序号，第一个序号从0开始计，最大的序号为partition数量减1，partition是实际物理上的概念，而topic是逻辑上的概念。
每个partition(目录)相当于一个巨型文件被平均分配到多个大小相等的segment(段)数据文件中(每个segment 文件中消息数量不一定相等)这种特性也方便old segment的删除，即方便已被消费的消息的清理，提高磁盘的利用率。
每个partition只需要支持顺序读写就行，segment的文件生命周期由服务端配置参数(log.segment.bytes，log.roll.{ms,hours}等若干参数)决定。
segment文件由两部分组成，分别为“.index”文件和“.log”文件，分别表示为segment索引文件和数据文件。
这两个文件的命令规则为：partition全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值，数值大小为64位，20位数字字符长度，没有数字用0填充
“.index”索引文件存储大量的元数据，“.log”数据文件存储大量的消息，
索引文件中的元数据-------------->指向对应数据文件中message的物理偏移地址
HW和LEO。这里先介绍下LEO，LogEndOffset的缩写，表示每个partition的log最后一条Message的位置。HW是HighWatermark的缩写，是指consumer能够看到的此partition的位置，这个涉及到多副本的概念，这里先提及一下，下节再详表。
ISR副本集合保存的副本的条件是什么？
上面一直说ISR副本集合中的副本就是和leader副本是同步的，那这个同步的标准又是什么呢？
答案其实跟一个参数有关：replica.lag.time.max.ms。
#小插曲
https://blog.csdn.net/wang704987562/article/details/72771417
alternatives --config java
alternatives --install /usr/bin/java java /usr/java/default/bin/java 500
#Leader选举算法非常多，
大数据领域常用的有 以下两种:
Zab(zookeeper使用);
Raft； ……
它们都是Paxos算法的变种。
它在所有broker中选出一个controller，所有Partition的Leader选举都由controller决定。controller会将Leader的改变直接通过RPC的方式
#副本的概念
https://www.cnblogs.com/jetqiu/p/11681838.html
#消费者组的概念
https://blog.csdn.net/gdkyxy2013/article/details/86644919
https://www.pianshen.com/article/673635248/
http://www.imooc.com/article/268855
https://www.cnblogs.com/lilytao/p/9929466.html
https://blog.csdn.net/roshy/article/details/88577903
[https://www.jianshu.com/p/2d85824e7d91](https://www.jianshu.com/p/2d85824e7d91)
zookeeper
#zookeeper 扩充
注意事项
首先，当我们要从3台扩充到5台时，应保证集群不停止服务。
3台不停止服务的最低限度是2台（X/2+1），而5台的最低限度是3台。
我们应该保证，集群中最低有3台ZooKeeper是启动的。
此外，重启时应保证先重启myid最小的机器，由小向大进行重启
Leader无论其myid大小，都放到最后重启
因为ZooKeeper的机制中，myid大的会向小的发起连接，而小的不会向大的发起连接。因此如果最后重启myid最小的机器，则其可能无法加入集群
https://www.cnblogs.com/liqing1009/p/7411685.html
找到原先配置中的数据保存地址，可以在zoo.cfg配置文件中查看，例如：dataDir=/data/zookeeper/data
到最新的日志文件和快照文件，
rw-r--r-- 1 root root 424 5月 4 15:40 snapshot.0
-rw-r--r-- 1 root root 67108880 5月 4 16:38 log.1
-rw-r--r-- 1 root root 20229 5月 4 16:44 snapshot.df
-rw-r--r-- 1 root root 67108880 5月 4 16:44 log.e0
日志文件存放zookeeper 全部数据记录 ，快照文件则是内存增量文件。
拷贝数据到新的zookeeper集群节点下，重启zookeeper服务，查看节点数据是否正常
#四字命令
zookeeper四字命令
https://www.cnblogs.com/kuku0223/p/8428341.html
#文件
https://www.cnblogs.com/cyl048/p/8984661.html
#协议
为了保证主从节点的数据一致性，Zookeeper采用了ZAB协议，这种协议非常类似于一致性算法 Paxos和Raft.
什么是ZAB？
Zookeeper Automic Broadcast,有效的解决了Zookeeper集群崩溃恢复，以及主从同步数据的问题。
ZAB协议定义的三种节点状态
Looking-选举状态
Following-从节点
Leader-主节点
#rabbitmq
https://blog.csdn.net/zwgdft/article/details/53561277
字符设备，块设备，套接字
https://www.cnblogs.com/iceJava/p/5377779.html
模块结构
https://www.cnblogs.com/fanzhidongyzby/p/3730131.html
内核通知链接
http://www.360doc.com/content/15/1126/13/496343_516031833.shtml
