Loading...
LVS-DR模型缺陷: https://blog.csdn.net/qq_43684922/article/details/128710261
2、LVS的DR和NAT模式下要注意的缺陷缺陷1：DR模式下的realserver和 lvs的vip提供服务的端口必须一致。例如vip的端口对外端口为 80，但后端服务的真实端口为8080，通过lvs的DR模式是实现不了的。原因： 因为LVS的DR模式，改写的就是数据包的目的MAC地址，并不会对数据报文IP和端口地址层修改，所以就作不到端口改写了。陷阱2：DR模式下，realserver和lvs不能在同一台机器上原因： 假设lvs主服务器上的数据包发送给自己备份节点（也是realserver） eth0 接口。备lvs不能正常的被监听指定端口的程序所接收，因为数据包会首先先经过 ip_vs()来接受处理了.不仅如此，备份节点还会将50％的机率将数据包转发给lvs主，这样一直主和备一直转发，就形成死循环了。所以客户端会发现，一次正常能请求，一次会出现超时的情况。正确做法： realserver 和lvs需要在同一个vlan或者局域网下陷阱3：DR模式下，Realserver 和LVS需要在同一个vlan或者局域网下？原因： lvs改写的是mac地址的，基于mac地址的通讯方式是2层的，所以需要限制在一个vlan或者局域网下。陷阱4：NAT模式下，NAT模式流量的入和出都需要通过lvs服务器原因： NAT模式修改的目的端的IP地址，对公网的VIP，并不会下放到realserver上，所以后端的realserver的网关必须指向lvs地址。陷阱5：NAT模式相比DR模式，性能和效率上会差一些原因： NAT模式出入的数据包都需要通过lvs，必然导致数量大了后，成为性能瓶颈。陷阱6：在DR模式下的ARP广播问题在DR模式下时，会存在一个问题，所有的realserver和director都配置了VIP，从网络模型中，我们知道，最终传输的是mac地址，那么这个时候，到底谁的mac地址是准确的呢？ 我们要保证请求的VIP必须是director，这样我们的负载均衡才是生效的，因此要在realserver上进行ARP抑制配置，禁止它处理外部的arp请求，也不允许自己向外部广播ARP数据
demo
32位CPU支持4GB内存的说法
CPU 32位表示最大只能输出 2^32个电信号, 因此最大值也是2^32. 一组32位的信号为一个内存地址, 最大也只能找到2^32-1个地址.
另外内存地址指向内存的不是bit, 而是一个由8bit组成的byte, 也就是一个内存地址代表1byte
换算为最大支持的内存为: 2^32/ 1024(MB) / 1024(GB) = 4096, 刚好4GB
C中的前置++, 如: int i = 1; int j = ++i; printf("i = %d; j = %dn", i, j) 表示先计算再使用, 此时j=2, i=2
C中的后置++, 如: int i = 1; int j = i++; printf("i = %d; j = %d\n", i, j) 表示先使用再计算, 此时j=1, i=2
Linux CPU使用率： 1 - 空闲时间/总时间
nginx的location优先级是：(location = /)>(localtion^~)>(location ~| ~* ）>(location /)
MySQL查看当前链接的线程MariaDB [(none)]> SHOW PROCESSLIST;
MariaDB [(none)]> SHOW PROCESSLIST;
莫回望
vue数据的双向绑定就是有一个上帝视角（观察者），数据发生改变就出通知视图修改数据
timedatectl set-ntp true 允许ntp同步时间
conda更新报错 'requests' 是conda的依赖，不能被删除，所以使用强制更新conda update --force conda
sorted(wordcount.itmes(), key=str)等价于key是对谁排序，以及什么类型排序如果数据是元组 data = ((1,2), (3,4))如果按字符串排序key=str <==> key=lambda x:str(x)x 表示就是可迭代对象的的每个数据 如：data[0]如果按照第一个元素排序key=lambda x:x[0] 表示按第一个元素排序key=lambda x:str(x[0]) 表示按第一个元素且按字符排序sorted(wordcount.itmes(), key=lambda x: str(x))
sorted 的 key = lambda x:x[?] 是固定写法，x其实可以为任意值。 x为第几个元素进行比较
二进制处理才是最快的
zip函数，顾名思义是一个打包函数如：a = [1,2,3,4]; b= [5,6,7,8]c = {zip(a,b)}c = {1:5, 2:6, 3:7, 4:8}
wget -O - -q URL 不保存直接打印
shc加密并不安全，直接ps -ef可见源代码
装饰器复制原函数的属性import functools@functools.wraps(src_func)
运维！运维！运维！
大家就当无事发生过
LVS-DR模型缺陷: https://blog.csdn.net/qq_43684922/article/details/128710261
2、LVS的DR和NAT模式下要注意的缺陷
缺陷1：DR模式下的realserver和 lvs的vip提供服务的端口必须一致。
例如vip的端口对外端口为 80，但后端服务的真实端口为8080，通过lvs的DR模式是实现不了的。
原因： 因为LVS的DR模式，改写的就是数据包的目的MAC地址，并不会对数据报文IP和端口地址层修改，所以就作不到端口改写了。
陷阱2：DR模式下，realserver和lvs不能在同一台机器上
原因： 假设lvs主服务器上的数据包发送给自己备份节点（也是realserver） eth0 接口。备lvs不能正常的被监听指定端口的程序所接收，因为数据包会首先先经过 ip_vs()来接受处理了.
不仅如此，备份节点还会将50％的机率将数据包转发给lvs主，这样一直主和备一直转发，就形成死循环了。所以客户端会发现，一次正常能请求，一次会出现超时的情况。
正确做法： realserver 和lvs需要在同一个vlan或者局域网下
陷阱3：DR模式下，Realserver 和LVS需要在同一个vlan或者局域网下？
原因： lvs改写的是mac地址的，基于mac地址的通讯方式是2层的，所以需要限制在一个vlan或者局域网下。
陷阱4：NAT模式下，NAT模式流量的入和出都需要通过lvs服务器
原因： NAT模式修改的目的端的IP地址，对公网的VIP，并不会下放到realserver上，所以后端的realserver的网关必须指向lvs地址。
陷阱5：NAT模式相比DR模式，性能和效率上会差一些
原因： NAT模式出入的数据包都需要通过lvs，必然导致数量大了后，成为性能瓶颈。
陷阱6：在DR模式下的ARP广播问题
在DR模式下时，会存在一个问题，所有的realserver和director都配置了VIP，从网络模型中，我们知道，最终传输的是mac地址，那么这个时候，到底谁的mac地址是准确的呢？ 我们要保证请求的VIP必须是director，这样我们的负载均衡才是生效的，因此要在realserver上进行ARP抑制配置，禁止它处理外部的arp请求，也不允许自己向外部广播ARP数据
demo
32位CPU支持4GB内存的说法
CPU 32位表示最大只能输出 2^32个电信号, 因此最大值也是2^32. 一组32位的信号为一个内存地址, 最大也只能找到2^32-1个地址.
另外内存地址指向内存的不是bit, 而是一个由8bit组成的byte, 也就是一个内存地址代表1byte
换算为最大支持的内存为: 2^32/ 1024(MB) / 1024(GB) = 4096, 刚好4GB
C中的前置++, 如: int i = 1; int j = ++i; printf("i = %d; j = %dn", i, j) 表示先计算再使用, 此时j=2, i=2
C中的后置++, 如: int i = 1; int j = i++; printf("i = %d; j = %d\n", i, j) 表示先使用再计算, 此时j=1, i=2
Linux CPU使用率： 1 - 空闲时间/总时间
nginx的location优先级是：(location = /)>(localtion^~)>(location ~| ~* ）>(location /)
MySQL查看当前链接的线程
MariaDB [(none)]> SHOW PROCESSLIST;莫回望
vue数据的双向绑定就是有一个上帝视角（观察者），数据发生改变就出通知视图修改数据
timedatectl set-ntp true 允许ntp同步时间
conda更新报错 'requests' 是conda的依赖，不能被删除，所以使用强制更新
conda update --force conda
sorted(wordcount.itmes(), key=str)
等价于
key是对谁排序，以及什么类型排序
如果数据是元组 data = ((1,2), (3,4))
如果按字符串排序
key=str <==> key=lambda x:str(x)
x 表示就是可迭代对象的的每个数据 如：data[0]
如果按照第一个元素排序
key=lambda x:x[0] 表示按第一个元素排序
key=lambda x:str(x[0]) 表示按第一个元素且按字符排序
sorted(wordcount.itmes(), key=lambda x: str(x))
sorted 的 key = lambda x:x[?] 是固定写法，x其实可以为任意值。
x为第几个元素进行比较
二进制处理才是最快的
zip函数，顾名思义是一个打包函数
如：a = [1,2,3,4]; b= [5,6,7,8]
c = {zip(a,b)}
c = {1:5, 2:6, 3:7, 4:8}
wget -O - -q URL 不保存直接打印
shc加密并不安全，直接ps -ef可见源代码
装饰器复制原函数的属性
import functools
@functools.wraps(src_func)