znew
将.Z压缩包重新转化为gzip命令压缩的.gz压缩包
补充说明
znew命令 用于将使用compress命令压缩的“.Z”压缩包重新转化为使用gzip命令压缩的“.gz”压缩包。
语法
znew(选项)(参数)
选项
-f：# 强制执行转换操作，即是目标“.gz”已经存在；
-t：# 删除原文件前测试新文件；
-v：# 显示文件名和每个文件的压缩比；
-9：# 食用油花的压缩比，速度较慢；
-P：# 使用管道完成转换操作，以降低磁盘空间使用；
-K：# 当“.Z”文件比“.gz”文件小时，保留“.Z”文件。
参数
文件：指定compress指令压缩生成的“.Z”压缩包。
在Git中，提交（commit）时使用的feat并不是一个Git本身定义的命令或关键字，而是遵循某种提交消息规范（如Angular的提交信息规范）时，用来表示提交类型的一种约定俗成的标记。这种规范通常用于帮助维护者快速理解每次提交的目的和范围，以及自动化生成变更日志（changelog）。
feat代表“feature”，即新功能。当你使用feat作为提交消息的一部分时，你正在向项目添加一个新的功能或特性。这是语义化版本控制（Semantic Versioning, SemVer）的一部分，它帮助开发者和用户理解项目的变化如何影响项目的版本号。
例如，一个包含feat的Git提交消息可能看起来像这样：
- feat: 添加用户登录功能
这个提交实现了用户的登录功能，包括用户名和密码的验证。 除了feat之外，还有其他类型的标记，比如：
- fix：表示修复了一个bug。
- docs：表示仅修改了文档。
- style：表示仅修改了代码的格式（比如空格、分号、缩进等），不改变代码逻辑。
- refactor：表示重构了代码，但没有添加新功能或修复bug。
- perf：表示提高了性能。
- test：表示增加了测试。
- chore（或choreograph、choreo等变体）：表示对项目结构或工具的更改，例如更新依赖项或配置文件。
遵循这样的提交消息规范有助于保持项目历史的清晰和一致性，特别是在大型项目或多人协作的项目中。它还有助于自动化工具（如commitizen、semantic-release等）的集成，这些工具可以根据提交消息来自动执行诸如生成变更日志、更新版本号等操作。
在 Nginx 的 proxy_pass 指令中，末尾的斜线（/）对代理行为有重要的影响。这主要涉及到请求 URI 的处理方式。
末尾不带斜线
如果你配置 proxy_pass 不带末尾的斜线，Nginx 会将请求的 URI 完整地传递给后端服务器，包括任何路径信息。
例如：
location /somepath/ {
proxy_pass http://localhost:8080;
}
当客户端请求 /somepath/foo 时，Nginx 会将请求代理到 http://localhost:8080/somepath/foo。
末尾带斜线
如果你配置 proxy_pass 带有末尾的斜线，Nginx 会修改请求的 URI，移除与 location 块匹配的部分，然后将剩余部分（如果有的话）传递给后端服务器。
例如：
location /somepath/ {
proxy_pass http://localhost:8080/;
}
当客户端请求 /somepath/foo 时，Nginx 会将请求代理到 http://localhost:8080/foo（注意 /somepath/ 部分被移除了）。
注意事项
当你在 location 块中使用正则表达式时，末尾的斜线通常不需要（或不建议）使用，因为正则表达式已经能够捕获到请求的 URI 部分。 如果你的后端服务器期望接收到完整的 URI（包括 location 块中定义的路径），那么你应该在 proxy_pass 中省略末尾的斜线。 如果你希望 Nginx 剥离 location 块中定义的路径部分，只将剩余的 URI 部分传递给后端服务器，那么你应该在 proxy_pass 中包含末尾的斜线。 示例 假设你有一个后端服务，它只响应根路径（/）下的请求。你可以使用以下配置来将所有到 /api/ 的请求代理到这个服务的根路径：
location /api/ {
proxy_pass http://localhost:8080/;
}
这样，无论客户端请求 /api/foo 还是 /api/bar，请求都会被代理到 http://localhost:8080/，并且后端服务可以在接收到请求后自行解析 /foo 或 /bar 部分。
参考：JAVA架构师笔记
API 网关有很多开源的实现，目前使用比较广泛的有以下几个：
- Kong 是在 Nginx 中运行的 Lua 程序。得益于 Nginx 的性能优势，Kong 相比于其它的开源 API 网关来说，性能方面是最好的。由于大中型公司对于 Nginx 运维能力都比较强，所以选择 Kong 作为 API 网关，无论是在性能还是在运维的把控力上，都是比较好的选择；
- Zuul 是 Spring Cloud 全家桶中的成员，如果你已经使用了 Spring Cloud 中的其他组件，那么也可以考虑使用 Zuul 和它们无缝集成。不过，Zuul1 因为采用同步阻塞模型，所以在性能上并不是很高效，而 Zuul2 推出时间不长，难免会有坑。但是 Zuul 的代码简单易懂，可以很好的把控，并且你的系统的量级很可能达不到 Netfix 这样的级别，所以对于 Java 技术栈的团队，使用 Zuul 也是一个不错的选择；
- Tyk 是一种 Go 语言实现的轻量级 API 网关，有着丰富的插件资源，对于 Go 语言栈的团队来说，也是一种不错的选择。
总结
-
API 网关分为入口网关和出口网关两类，入口网关作用很多，可以隔离客户端和微服务，从中提供协议转换、安全策略、认证、限流、熔断等功能。出口网关主要是为调用第三方服务提供统一的出口，在其中可以对调用外部的 API 做统一的认证、授权，审计以及访问控制；
-
API 网关的实现重点在于性能和扩展性，你可以使用多路 I/O 复用模型和线程池并发处理，来提升网关性能，使用责任链模式来提升网关的扩展性；
-
API 网关中的线程池，可以针对不同的接口或者服务做隔离和保护，这样可以提升网关的可用性；
-
API 网关可以替代原本系统中的 Web 层，将 Web 层中的协议转换、认证、限流等功能挪入到 API 网关中，将服务聚合的逻辑下沉到服务层。
API 网关可以为 API 的调用提供便捷，也可以为将一些服务治理的功能独立出来，达到复用的目的，虽然在性能上可能会有一些损耗， 但是一般来说， 使用成熟的开源 API 网关组件，这些损耗都是可以接受的。所以，当你的微服务系统越来越复杂时，你可以考虑使用 API 网关作为整体系统的门面。
全文复制保存方便自己查看。
1、Protobuf编码原理介绍
序列化算法被广泛应用于各种通信协议中，本文对序列化算法进行狭义定义：
将某个struct或class的内存数据和通信数据链路上的字节流进行互相转化的算法。
基于这个定义序列化算法具有两个行为：
1、序列化：内存数据->通信链路字节流
2、反序列化：通信链路字节流->内存数据
常用的序列化算法有：json、xml、protobuf 等，将这些算法进行归纳不难发现这些算法主要是对三种基本类型（原子性、不可被拆分）和三种复合类型（由基本类型和其他符合类型构成）进行序列化和反序列化。
1、基本类型：定点数值类型、浮点数值类型、字符串类型
2、复合类型：结构体类型、数组类型、map类型
protobuf也是对这些类型进行序列化的，下文将在proto3语法的背景下介绍protobuf对不同类型的编码原理。
1.1 基本类型
1.1.1 定点数值类型
proto3语法中：int32、int64、uint32、uint64、sint32、sint64、fixed32、fixed64、sfixed32、sfixed64、bool、enum属于定点数值类型。对于int32、int64、uint32、uint64会直接使用varint编码，bool类型会直接使用一个字节存储，enum可以看成是一个int32类型。对于sint32、sint64类型会先进行zigzag编码，再进行varint编码，对于fixed32、fixed64、sfixed32、sfixed64类型会使用定长的四个或八个字节进行存储。
关于varint编码和zigzag编码的细节可以参考文档https://protobuf.dev/programming-guides/encoding/ ，本文直接给出两种编码的性质：
varint编码：变长编码，对于小正整数有较好的压缩效果，对于大整数或负数编码后字节流长度会变大。
zigzag编码：定长编码，将小正整数和小负整数转换到小正整数再进行varint编码，对绝对值较小的整数有良好的压缩效果。
1.1.2 浮点数值类型
proto3语法中：float和double属于浮点数据类型，使用定长的四个字节或八个字节存储，数据直接用IEEE754标准表示。
1.1.3 字符串类型
proto3语法中：string、bytes属于字符串类型，字符串类型序列化后的字节流为其原始内容本身。这两种类型的不同之处在于string内的字节流必须是utf8编码，bytes没有这种要求。
1.2 复合类型
1.2.1 结构体类型
proto3语法中使用message定义结构体类型，结构体类型有多个不同tagid构成的字段，字段可以是基本类型或复合类型，甚至可以是这个结构体类型本身。结构体每个字段底层都使用这种格式进行存储，需要注意的是typeid、length、data三部分长度会根据实际情况发生改变。
typeid length data
+--------+--------+--------+
|xxxxxxxx|xxxxxxxx|xxxxxxxx|
+--------+--------+--------+
typeid用于存储结构体字段编号（tagNum）和字段类型（tagType），tagNum为字段“=”后的数字，tagNum也使用varint进行编码，因此如果“=”后的数字很大，则可能导致tagNum编码变大，tagid占用多个字节。而tagType则指明数据类型，这部分固定占用三个bit。
|tagNum |tagType|
+----------------------+
|x x x x x x x x|
+----------------------+
7 2 0
下表记录了不同字段类型对应的tagType值：
| tagType | 类型 |
|---|---|
| 0 | int32、int64、uint32、uint64、sint32、sint64、bool、enum |
| 1 | fixed64、sfixed64、double |
| 2 | string、bytes、结构体类型、数组类型、map类型 |
| 3 | 弃用 |
| 4 | 弃用 |
| 5 | fixed32、sfixed32、float |
length部分表示data部分的长度，同样使用变长varint编码，需要注意的是如果字段类型是数值类型，则length部分不会出序列化后的字节流中。
data部分为原始数据，可以是基本类型和复合类型序列化后的字节流，算法通常递归的对这些字段进行处理。
虚拟机通过DHCP获取IP的过程通常包括以下步骤：
DHCP Discover：虚拟机启动时，会发送一个DHCP Discover广播包到网络中，该包中包含了对DHCP服务器的请求。
14:31:53.831654 fa:16:3e:d6:62:84 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:d6:62:84, length 300, xid 0x6265ab6d, Flags [none] (0x0000)
Client-Ethernet-Address fa:16:3e:d6:62:84
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Requested-IP Option 50, length 4: 1.1.1.13
Parameter-Request Option 55, length 13:
Subnet-Mask, BR, Time-Zone, Classless-Static-Route
Domain-Name, Domain-Name-Server, Hostname, YD
YS, NTP, MTU, Option 119
Default-Gateway
DHCP Offer：网络中的DHCP服务器接收到DHCP Discover广播包后，会向虚拟机发送一个DHCP Offer广播包，其中包含了可用的IP地址、子网掩码、网关、DNS服务器等信息。
/etc/logrotate.conf 文件是系统级别的 logrotate 配置文件，它通常用于配置全局的日志轮转规则和选项。如果您希望针对您的项目或应用程序设置特定的日志轮转规则，
可以创建一个单独的 logrotate 配置文件并将其放置在 /etc/logrotate.d/ 目录中。
下面是一些步骤来创建并使用一个针对您的项目的 logrotate 配置文件：
创建配置文件：
在 /etc/logrotate.d/ 目录中创建一个新的文件，可以使用您项目的名称或相关描述来命名该文件，例如 my_project_logrotate。
编辑配置文件：
使用文本编辑器（如vi或nano）编辑该文件，添加您项目的日志文件、轮转规则和选项。以下是一个简单的示例：
/path/to/your/project/logs/*.log {
daily
rotate 7
compress
delaycompress
missingok
notifempty
create 0644 <user> <group>
su <user> <group>
}
- daily：每天轮转日志。
- rotate 7：保留最多7个旧日志文件。
- compress：压缩轮转后的日志文件。
- delaycompress：在下一次轮转时再压缩旧的日志文件。
- missingok：如果日志文件丢失，不发出警告消息。
- notifempty：如果日志文件为空，则不轮转。
- create 0644 ：创建新的日志文件并设置权限。
- su ：指定轮转时使用的用户和组。
将上述配置中的 /path/to/your/project/logs/*.log 替换为实际项目日志文件的路径和模式。
无领导小组讨论
角色解读
记录者 Recorder
- 记录清晰，重点标明
- 配合领导者，解决盲点，推进讨论;
- 恰当总结发言，争取做代表来总结陈述
协调者 Coordi-nator
- 组织协调者是调动团队气氛、调和大家的意见、调配发言权的考生。在无领导小组讨论面试当中，组织协调者这个角色要求考生具有较强的亲和力，能够将整个团队的讨论氛围提上去，充分调动大家的积极性，展开头脑风暴式的讨论
- 组织协调者应该是一个性情平和，无论是说话风格还是思维都不太有威胁性和刺激性的人，但须头脑清醒，始终牢记整个讨论的目的。
普通成员
随时可以客串其他角色(辅助角色)
评价标准解读
- 参与有效发言的次数;（参与程度）
- 是否有随时消除紧张气氛、说服别人、调解争议，并且创造一个使不爱讲话的人也想发言的能力，并使众人的意见达到一致;（影响力）
- 能不能提出自己的见解和方案，同时敢于发表不同意见，并支持肯定他人的意见，在坚持自己正确意见的基础上，根据别人的意见发表自己的观点; （整合能力）
- 能够倾听别人的意见，并且相互尊重，在别人发言时不强行插嘴；（人际沟通）
- 语言表达、分析问题、概括或者归纳总结不同方面意见的能力;（表达能力、逻辑能力）
- 反应的灵敏性、概括的正确性和发言的主动性;（灵活适应）
注意事项
- 把握讨论方向，让大家不跑题
- 发言积极主动，面试开始，先亮出自己的观点，留下好印象，还能引导大家前行
- 人际:能与团队成员建立信任
- 说服对方 (别人可接受的方式)
- 言辞专业、真诚可信赖
- 关注问题本质
- 摆事实、讲道理
- 先肯定再转折
- 求同存异取长补短，面试开始不要急于表述看法，完善思路
- 表达观点的逻辑
解锁思路
面试官： 请介绍一个过往你在做团队领导者时让你印象深刻的经历
- What
先用一句话简明扼要的回答面试官的问题，比如：负责某某项目让我印象深刻。
- Star法则
S：Situation 发生的时间、地点、项目、人物等等，还有背景及困难
T：Task 任务及目标
A：Action 遇到问题后自己采取了哪些行动
R：Result 收获了怎样的结果及影响
- 关键词
你负责，为何印象深刻？
面试技巧
- 拿出最真实，最优秀的自己
- 注重面试的基本礼仪及言谈
- 调整好心态，克服紧张情绪
- 微笑会为面试增加砝码
- 重视个人语言表达能力
- 重视面试开头的三分钟
- 沉着从容地应对面试
- 优缺点的回答技巧:先抑后扬
- 对于意想不到的问题:不要思考太久
- 面试结束后的复盘、经验总结
- 成功在于展现自己优势
- 诚信永远不过时;
- 把控好自我推销的分寸
- 过分谦虚会错失机会;
- 自我介绍要紧扣岗位需求主题，控制好时间;
- 回答问题要有针对性
- 谈及缺点的时候不要自作聪明
- 候选人提问环节应抛出合适的问题,
- 被追问的情况: 空话套话，角色、动作不清，聚焦情景，结果澄清
- 有明确的职业定位和清晰的发展目标(尤其跨专业)
面试准备
取法其上得乎其中，取法其中得乎其下
$ mysql -u root -p
Create the keystone database:
MariaDB [(none)]> CREATE DATABASE keystone;
Grant proper access to the keystone database:
GRANT ALL PRIVILEGES ON yong.* TO 'yong'@'localhost' IDENTIFIED BY '123456';
GRANT ALL PRIVILEGES ON yong.* TO 'yong'@'%' IDENTIFIED BY '123456';