Reprint

Kafka 文件存储机制 Kafka 是什么 Kafka 是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统(也可以当做MQ系统)，常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。 1.前言 一个商业化消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。 下面将从Kafka文件存储机制和物理结构角度，分析Kafka是如何实现高效文件存储，及实际应用效果。 2.Kafka文件存储机制 Kafka部分名词解释如下: Broker: 消息中间件处理结点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。 Topic: 一类消息，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能够同时负责多个topic的分发。 Partition: topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。 Segment: partition物理上由多个segment组成，下面2.2和2.3有详细说明。 offset: 每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset,用于partition唯一标识一条消息. 分析过程分为以下4个步骤: topic中partition存储分布 partiton中文件存储方式 partiton中segment文件存储结构 在partition中如何通过offset查找message 通过上述4过程详细分析，我们就可以清楚认识到kafka文件存储机制的奥秘。 2.1 topic中partition存储分布 假设实验环境中Kafka集群只有一个broker，xxx/message-folder为数据文件存储根目录，在Kafka broker中server.properties文件配置(参数log.dirs=xxx/message-folder)，例如创建2个topic名称分别为report_push、launch_info, partitions数量都为partitions=4 存储路径和目录规则为: 复制代码 xxx/message-folder |--report_push-0 |--report_push-1 |--report_push-2 |--report_push-3 |--launch_info-0 |--launch_info-1 |--launch_info-2 |--launch_info-3 复制代码 在Kafka文件存储中，同一个topic下有多个不同partition，每个partition为一个目录，partiton命名规则为topic名称+有序序号，第一个partiton序号从0开始，序号最大值为partitions数量减1。 如果是多broker分布情况，请参考kafka集群partition分布原理分析 2.2 partiton中文件存储方式 下面示意图形象说明了partition中文件存储方式: image 图1 每个partion(目录)相当于一个巨型文件被平均分配到多个大小相等segment(段)数据文件中。但每个段segment file消息数量不一定相等，这种特性方便old segment file快速被删除。 每个partiton只需要支持顺序读写就行了，segment文件生命周期由服务端配置参数决定。 这样做的好处就是能快速删除无用文件，有效提高磁盘利用率。 2.3 partiton中segment文件存储结构 读者从2.2节了解到Kafka文件系统partition存储方式，本节深入分析partion中segment file组成和物理结构。 segment file组成: 由2大部分组成，分别为index file和data file，此2个文件一一对应，成对出现，后缀".index"和".log"分别表示为segment索引文件、数据文件. ...

响应式编程, Reactive Programming, 反应式编程 Reactive Programming 作为观察者模式 (Observer） 的延伸，不同于传统的命令编程方式 ( Imperative programming） 同步拉取数据的方式，如迭代器模式 (Iterator）。而是采用数据发布者同步或异步地推送到数据流 (Data Streams）的方案。当该数据流 (Data Steams）订阅者监听到传播变化时，立即作出响应动作。在实现层面上，Reactive Programming 可结合函数式编程简化面向对象语言语法的臃肿性，屏蔽并发实现的复杂细节，提供数据流的有序操作，从而达到提升代码的可读性，以及减少 Bug 出现的目的。同时，Reactive Programming 结合背压 (Backpressure） 的技术解决发布端生成数据的速率高于订阅端消费的问题。 https://developer.aliyun.com/article/617709 响应式编程为 Java 的企业版应用提供了更高的性能，并降低了内存消耗，主要是通过减少进程的上下文切换来实现的。因为类似的上下文切换对 CPU 和内存的消耗是极大，所以要尽可能的减少这样的切换操作。不过，响应式编程带来的这种性能上的提高，代价是降低了软件的维护性 java 使用一对一的线程模型,一个java线程对应一个内核线程, 高并发情况下 线程上下文切换成为了瓶颈. 而这正是响应式编程的用武之地，它与目前的 Java 线程模型完全相反。目前的线程模型是保证所有的事情都在当前线程执行，但是在响应式编程中，异步是一个准则。一个程序执行过程被认定为一系列异步执行的事件，每个事件都被 Publisher 创建，你不需要关心 Publisher 在哪个线程中创建。在响应式程序里面，程序代码包含了监听和执行异步事件的功能，而且会在必要时提供新的事件。 这个方式在某些场景下很有效果，比如说在程序里面访问外部数据库。传统的企业级 Java 程序里面，系统会发送一段 SQL 语句到数据库上面，阻塞住程序，直到数据库返回查询结果。但是在响应式编程里面，程序会跳过等待结果的过程，正常向下执行代码。当你发送一个 SQL 请求到数据库的时候，会用一个 Pushlisher 来替代阻塞的过程，调用者可以注册这个 Pushlisher，这样的话，在之后数据库返回结果的时候，就会通知 Publisher，然后 Publisher 会通知调用者。 响应式编程的好处就是执行的代码和执行的线程是分开的。因此在操作系统的层面上，上下文切换的代价比较低。 响应式编程也有一些比较严重的问题，写入的代码和执行的代码分离开来，导致阅读和编写代码的难度增加，对于这种异步的代码，编写单元测试和调试代码都很困难。 类似于 C Sharp、JavaScript、Kotlin 等这一类的编程语言在这个领域已经走在了前面，他们在编程语言中集成了这部分功能，可以帮助你执行一小段异步代码，并在返回的时候阻塞，直到执行结束。在 C Sharp 和 JavaScript 中，可以使用 Async 和 Await 关键字，在 Go 和 Kotlin 中，同样包括了协程的概念来提供类似的功能。 ...

maven-shade-plugin maven build fat jar

‘命令行, curl 查询公网 ip’ curl ifconfig.me curl whatismyip.akamai.com curl https://ip.cn curl icanhazip.com curl ident.me curl tnx.nl/ip curl myip.dnsomatic.com https://blog.csdn.net/liu0808/article/details/80769810 curl http://members.3322.org/dyndns/getip # 保存到文件 wget http://ifconfig.me/ip wget http://members.3322.org/dyndns/getip http://blog.csdn.net/teddy17/article/details/12618035 curl http://myip.ipip.net/ curl cip.cc curl ifconfig.me curl myip.ipip.net curl http://members.3322.org/dyndns/getip

shell basic, shell script sample #!/usr/bin/env bash echo 'hello world' commands # to refresh your current bash session exec bash Shell 函数, function # 参数不在函数名后面的括号里定义 [ function ] funname [()] { action; [return int;] } # 定义函数 fun0 fun0(){ echo "run fun0: " + $1 } # 调用函数 fun0 fun0 "foo" # 定义带参数的函数 fun0 # 在Shell中，调用函数时可以向其传递参数。在函数体内部，通过 $n 的形式来获取参数的值，例如，$1表示第一个参数，$2表示第二个参数... fun0(){ echo "run fun0 $1 " echo "第一个参数为 $1 !" echo "第二个参数为 $2 !" echo "第十个参数为 $10 !" } # 调用带参数的函数 fun0 fun0 foo # check if params is not supplied if [ $# -eq 0 ] then echo "No arguments supplied" fi https://www.runoob.com/linux/linux-shell-func.html ...

用户故事, user story 故事story是粗略的勾勒的需求，它是信！号！卡！，指向真正的需求或者叫故事详情，怎么说都好。 而需求就是需求。 这里隐含了敏捷的一个要素，就是，延！迟！决！策！ 当需求不是被细化的摆放着，而是粗略的STORY的时候，才能更好的表达延迟决策。首先我们并不在一开始就把所有的东西都想清楚，而是仅仅以STORY的方式跟踪记录我们未来要做的事情。当开发前，我们才去细化STORY故事，把他变成需求。或者，开发前，我们扔掉STORY，因为它已经不重要了。see。故事可以帮我们更好的做延迟决策。保证所有的事情是在开发前才定下来的，而且保证我们不会遗漏。所以这里，就是为什么敏捷要用STORY而不是需求去进行需求的管理。 作者: 马菲菲 链接: https://www.zhihu.com/question/26996772/answer/35078718 来源: 知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 用户故事 https://www.tapd.cn/forum/view/43571 https://www.cnblogs.com/jetlian/p/3946359.html http://www.scrumcn.com/agile/scrum/4823.html http://www.scrumcn.com/agile/scrum/20026.html https://blog.csdn.net/GitChat/article/details/78410016 用户故事 (User Story) 和验收标准 (Acceptance Criteria) 那么什么是用户故事呢？一个用户故事就是一个功能或者feature的需求 (requirement) ，被写出了也就一两行字，最多5行。一个用户故事通常是最简单的可能性需求，有且只能是一个功能或feature。最常见使用的标准格式的用户故事如下: 作为一个用户/客户角色，我想要达到的目标是什么，以及达到目标的原因e.g:作为社交工具微信的用户，我想要在聊天对话框中有一个拍照图标去自拍和发照片，那么我就可以和朋友一起相互发照片。 什么是验收标准？验收标准就是一系列可以接受的条件或者业务规则，且与功能或feature相互匹配和满足，同时也能被产品负责人和相关人接受。这是用户故事完成很重要的一部分，它需要被产品负责人和业务分析人员认真的学习，因为错失一个很小的标准都会损失惨重。这是简单的编号或者编号列表。格式如下: 在我做某些动作 (action) 之前请赐给一些先决条件，然后期望结果发生。举个栗子: 1. 假设我正在和朋友聊天，我应该能够拍照2. 当我点击照片时，我应该可以在照片上添加一些文字，然后发给朋友3. 如果我的手机照相机有问题，一条错误信息，如"摄像头无法打开"…，相应的也应该出现因此，用户故事为任何功能或feature定义了需求，另一方面，验收标准为用户故事或需求定义了"完成标准的定义"。作为QA，理解用户故事非常重要，同时深刻理解验收标准，并且在测试开始前没有一点的疑惑。 https://www.jianshu.com/p/bde45187a78f

Theme, epic,feature,user story 在敏捷项目的估算或计划时，我们常提到以下几个概念。talent.mypm.net · Epic Storyservice.mypm.net · Feature项目经理圈子 · Minimal Marketable Feature (MMF)项目管理者联盟 · Theme项目管理者联盟 · User Story项目管理培训 · Tasktalent.mypm.net 本文将说明这几个概念的意义和他们间的关系。项目管理者联盟 FeaturePgMp.mypm.net Feature是可以为顾客提供价值的东西，它代表一个产品可以做什么，或提供什么服务;是可以满足用户的需求，为客户服务，为用户带来真正的价值的成果物的特性。PgMp.mypm.net Feature相对复杂，可由一组动宾结构的句子表达，如一个超市的交易可以描述为: blog.mypm.net · 扫描条形码项目管理者联盟 · 显示单价PgMp.mypm.net · 计算总价项目管理者联盟 · 计算税额项目管理者联盟 · 打印清单项目管理者联盟文章 因此，一个Feature是很难进行估算的，它需要被分解成一个个更小的单位，这就是下面要讨论的User Story。Feature一般在Release Plan的层次，一个Feature可能需要几次迭代才能完成。项目管理者联盟 由于Feature是满足用户需求的交付物，因此每次交付的对象应该是一个或多个Feature。可以说Feature就是敏捷宣言中的"Working software"。转自项目管理者联盟 Minimal Marketable Feature (MMF)项目管理者联盟 了解了什么时Feature后，我们再来讨论MMF。顾名思义，MMF就是一组最小的，可以市场化的机能。首先，它是Feature，其次，它强调的是市场化这个概念。市场化意味着它能够提交到用户手中使用，并可以从用户那里得到相应的回报。MMF可以使得投资提前取得收益，这对于一个企业来说，是非常重要和实用的。blog.mypm.net User Story项目管理者联盟 在Feature的讨论中提到了，Feature是由一组动宾结构的句子组成的。这些动宾句子描述的就是一个个User Story。一个Feature可以分解成多个User Story，每个User Story不能单独被使用，而是一起构成一个Feature。PgMp.mypm.net 一个User Story必须是清晰的，可以为客户增加价值，而且更重要的是能够被估算。因此User Story通常是进行估算的基本单位，通常使用Story Point来进行估算。User Story是在迭代的层级，一个User Story要在一个迭代内完成。项目管理者联盟文章 另外，User Story也是进行需求分析的工具。通过询问谁、做什么、为什么，能够简单明了地扑捉客户的需求。因此User Story通常写成以下形式: 项目经理圈子 As a , I want , so than .项目管理者联盟 ...

hyper -v 端口映射 https://www.cnblogs.com/cnxkey/articles/7815434.html hyper -v 如何实现端口映射 如果你是想由虚拟机来提供相应的服务，比如虚拟机里安装web服务，将物理主机的web端口映射到虚拟机，可以使用如下命令进行设置即可，我已经成功了。 一、查询端口映射情况 netsh interface portproxy show v4tov4 查询这个IP所有的端口映射。 netsh interface portproxy show v4tov4|find “192.168.1.1” 二、增加一个端口映射 netsh interface portproxy add v4tov4 listenport=外网端口 listenaddress=主IP connectaddress=私网IP connectport=私网IP端口 例如: netsh interface portproxy add v4tov4 listenport=8888 listenaddress=118.123.13.180 connectaddress=192.168.1.10 connectport=2222 三、删除一个端口映射 netsh interface portproxy delete v4tov4 listenaddress=主IP listenport=外网端口 例如: netsh interface portproxy delete v4tov4 listenaddress=118.123.13.180 listenport=8888 在关闭Hyper-V虚拟机的情况下，选择Hyper-V管理界面中的"虚拟交换机管理器" 在弹出的对话框中"新建虚拟网络交换机"，选择"内部"，点击"创建虚拟交换机"。 在IP网卡 切换到"共享"标签下，勾选"允许其他网络用户通过此计算机的Internet连接来连接"并在下方"家庭网络连接"中选择刚刚创建的虚拟交换机——vEthernet (Hyper-V Switch)，点击"确认

Product Backlog Product Backlog由所有的功能特性，包括业务功能，非业务功能 (技术、架构和工程实践相关) ，提升点以及缺陷的修复等组成。这些内容也是将来产品版本发布的主要内容。 一个完整的Backlog是一个蓝图，可以根据它来把产品改造成为我们期望的样子。 但是在Scrum中，Backlog是根据产品和产品使用环境的演化而不断演化的。所以Backlog是动态的，我们会持续的改变它去确保我们的产品是最合理的，最有竞争力的，最有价值的。 当我们去看产品的Backlog的时候，优先级是一个重要的视角，优先级越高的Backlog需要越清晰，越详细。对于优先级低的Backlog，详细程度会越低，直到几乎我们不能认为它是一个Backlog项 (非常低的优先级，只相当于一个占位符，来用做提醒) 。 评算(Esitimate) 对每个backlog项做估算 (包括成本，复杂度，风险，功能点) 。优先级越高的Backlog估算要越精确，在估算的过程中可能会导致backlog的优先顺序有可能随之发生变化 (对于那些很重要，并且可以快速解决的问题可以先做) 。 我们要经常做估算。 创建者(Creater) Backlog内容的来源是多样化的. 产品营销部门会分析产生产品的特性和功能点，销售也会有很多反馈可以使产品更具有竞争力或者取悦某些特殊的客户。产品的架构师或者设计人员也会提出一些技术架构方面或者工程实践方面的需求使得产品更加灵活，更具扩展性，可复用性，开发更高效等等。产品实施或者技术支持部门也会有许多产品缺陷的反馈被放入Backlog。 重要程度(Importance) 每个Backlog项都有优先级，这些backlog项按照优先次序排行队列放在Backlog列表中。在评估的过程中 我需要在"什么样的产品特性，技术架构，缺陷的修复才会给产品公司和它的客户带来带来最大的收益？ " 和"什么样的技术架构，工程方法使我们可以更快，更高质量的交付版本"之间做出抉择。不论是对内部技术环境或者外部市场，我们都需要不断筛选和评估什么是最重要的。 版本发布(Release) 规划接下来的几个版本，包括版本的目标，及可能包含的内容。 (我们可能需要在发布内容，开发成本及发布周期之间做出抉择) 。 产品Backlog要按照Release分组，要让开发团队的所有成员都全部的了解总体开发目标，并且确保所有的技术问题都做了充分的考虑并且放入了产品Backlog. 负责人(Product Owner) 我们需要指定一个负责人来管理Backlog。这个人的职责是管理和控制Backlog列表，对于商业产品的开发， Backlog的负责人也许会是产品经理，对于内部项目的开发Backlog的负责人有可能是项目经理或者它指派的人。这个负责人的职责是调整产品Backlog的优先级和工作量估算，同时决定哪些内容包括在Sprint中。这是一个各个相关的组织协作的过程。 优先级(Priority) 只有一个人来进行排序的工作，这个人的职责是确保达成产品的愿景，提高产品投资回报率。这个人的职位一般是产品经理或者产品营销经理。如果任何人需要改变优先级，他们必须说服这个负责人去改变。 可视化(Visualization) 产品的Backlog需要能够让开发团队，利益相关者等相关的人能够很容易的看到它的内容，状态，进展等等。 以下是引用《硝烟中的Scrum和XP-我们如何实施Scrum (Henrik Kniberg著) 》 中讲述他们如何编写Product Backlog: Product Backlog是Scrum的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。我们叫它故事 (Story) ，有时候也叫做Backlog条目。 我们的故事包括这样一些字段: ID——统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。 Name (名称) ——简短的、描述性的故事名。比如"查看你自己的交易明细"。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。 Importance (重要性) ——产品负责人评出一个数值，指示这个故事有多重要。例如10或150。分数越高越重要。 o 我一直都想避免"优先级"这个说法，因为一般说来优先级1都表示"最高"优先级，如果后来有其他更重要的东西就麻烦了。它的优先级评级应该是什么呢？优先级0？优先级-1？ Initial Estimate (初始估算) ——团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点 (story point) ，一般大致相当于一个"理想的人天 (man-day) “。 o 问一下你的团队，“如果可以投入最适合的人员来完成这个故事 (人数要适中，通常为2个) ，把你们锁到一个屋子里，有很多食物，在完全没有打扰的情况下工作，那么需要几天，才能给出一个经过测试验证，可以交付的完整实现呢？“如果答案是"把3个人关在一起，大约需要4天时间”，那么初始估算的结果就是12个故事点。 o 不需要保证这个估值绝对无误 (比如两个故事点的故事就应该花两天时间) ，而是要保证相对的正确性 (即，两个点的故事所花费的时间应该是四个点的故事所需的一半) ...

Bcrypt https://www.jianshu.com/p/2b131bfc2f10 Bcrypt 是单向 Hash 加密算法，类似 Pbkdf2 算法 不可反向破解生成明文。 每次输出的 hashPass 都不一样， Bcrypt 是怎么加密的？ Bcrypt 有四个变量: saltRounds: 正数，代表hash杂凑次数，数值越高越安全，默认10次。 myPassword: 明文密码字符串。 salt: 盐，一个128bits随机字符串，22字符 myHash: 经过明文密码password和盐salt进行hash，个人的理解是默认10次下 ，循环加盐hash10次，得到myHash 每次明文字符串myPassword过来，就通过10次循环加盐salt加密后得到myHash, 然后拼接BCrypt版本号+salt盐+myHash等到最终的bcrypt密码 ，存入数据库中。 这样同一个密码，每次登录都可以根据自省业务需要生成不同的myHash, myHash中包含了版本和salt，存入数据库。 作者: martin6699 链接: https://www.jianshu.com/p/2b131bfc2f10 来源: 简书 简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。 https://www.ujcms.com/knowledge/509.html http://www.mindrot.org/projects/jBCrypt/ https://www.cnblogs.com/jpfss/p/11024716.html http://www.mindrot.org/projects/jBCrypt/ 在 Java 中使用 Bcrypt, BCryptPasswordEncoder 如果引入了 Spring Security, BCryptPasswordEncoder 提供了相关的方法。 public class BCryptPasswordEncoderTest { public static void main(String[] args) { String pass = "admin"; BCryptPasswordEncoder bcryptPasswordEncoder = new BCryptPasswordEncoder(); String hashPass = bcryptPasswordEncoder.encode(pass); System.out.println(hashPass); boolean f = bcryptPasswordEncoder.matches("admin",hashPass); System.out.println(f); } } 可以看到，每次输出的 hashPass 都不一样， 但是最终的f都为 true,即匹配成功。 ...

openvpn docker export OVPN_DATA="ovpn-data" docker volume create --name $OVPN_DATA docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm kylemanna/openvpn ovpn_genconfig -u udp://home.wiloon.com docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm -it kylemanna/openvpn ovpn_initpki docker run -v $OVPN_DATA:/etc/openvpn -d -p 192.168.50.220:1194:1194/udp --cap-add=NET_ADMIN --name openvpn --restart=always kylemanna/openvpn docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm -it kylemanna/openvpn easyrsa build-client-full client0 nopass docker run -v $OVPN_DATA:/etc/openvpn --log-driver=none --rm kylemanna/openvpn ovpn_getclient client0 > client0.ovpn # Retrieve the client configuration with embedded certificates docker run -v $OVPN_DATA:/etc/openvpn --rm kylemanna/rpi-openvpn ovpn_getclient client0 > client0.ovpn docker run -v $OVPN_DATA:/etc/openvpn -p 1194:1194/udp --privileged -e DEBUG=1 kylemanna/rpi-openvpn server 192.168.255.0 255.255.255.0 verb 3 key /etc/openvpn/pki/private/xxxx.key ca /etc/openvpn/pki/ca.crt cert /etc/openvpn/pki/issued/xxx.crt dh /etc/openvpn/pki/dh.pem tls-auth /etc/openvpn/pki/ta.key key-direction 0 keepalive 10 60 persist-key persist-tun proto udp # Rely on Docker to do port mapping, internally always 1194 port 1194 dev tun0 status /tmp/openvpn-status.log user nobody group nogroup comp-lzo no ### Route Configurations Below route 192.168.254.0 255.255.255.0 ### Push Configurations Below push "block-outside-dns" push "dhcp-option DNS 192.168.50.1" push "comp-lzo no" push "redirect-gateway def1 bypass-dhcp"

database DDL > puml https://github.com/wangyuheng/ddl2plantuml java -jar ~/apps/ddl2plantuml.jar foo.sql er.puml docker run \ -e DDL='/mnt/data/ddl.sql' \ -e PLANTUML='/mnt/data/er_by_docker.puml' \ -v ddl2plantuml-data:'/mnt/data' \ wangyuheng/ddl2plantuml:latest

nginx location, root location 语法 Location 块通过指定模式来与客户端请求的URI相匹配。 Location 基本语法： 匹配 URI 类型，有四种参数可选，当然也可以不带参数。 命名 location，用@来标识，类似于定义goto语句块。 location [ = | ~ | * | ^ ] /URI { … } location @/name/ { … } location 匹配命令解释 空 location 后没有参数直接跟标准 URI， 表示前缀匹配，代表跟请求中的 URI 从头开始匹配。 = 用于标准 URI 前，要求请求字符串与其精准匹配，成功则立即处理，nginx 停止搜索其他匹配。 ^~ 用于标准 URI 前，并要求一旦匹配到就会立即处理，不再去匹配其他的正则 URI，一般用来匹配目录 ~ 用于正则 URI 前，表示 URI 包含正则表达式，区分大小写 ~* 用于正则 URI 前， 表示 URI 包含正则表达式，不区分大小写 @ @ 定义一个命名的 location，@ 定义的locaiton名字一般用在内部定向，例如error_page, try_files命令中。它的功能类似于编程中的goto。 location 匹配顺序 nginx 有两层指令来匹配请求 URI。第一个层次是 server 指令，它通过域名、ip 和端口来做第一层级匹配，当找到匹配的 server 后就进入此 server 的 location 匹配。 ...

golang 开发目录结构 https://github.com/golang-standards/project-layout 在实际的项目中发现大家的目录结构都比较凌乱，基本每个人都有每个人的风格，一个项目在不断地变大，一些新的文件或目录又不断地被添加进来，从这里面去找到自己需要的信息的成本越来越高，一个统一的通用的目录结构非常有必要。 以下内容来自于github上的这个项目 (https://github.com/golang-sta…) /cmd main函数文件 (比如 /cmd/myapp.go) 目录，这个目录下面，每个文件在编译之后都会生成一个可执行的文件。 不要把很多的代码放到这个目录下面，这里面的代码尽可能简单。 /internal 应用程序的封装的代码，某个应用私有的代码放到 /internal/myapp/ 目录下，多个应用通用的公共的代码，放到 /internal/common 之类的目录。 /pkg 一些通用的可以被其他项目所使用的代码，放到这个目录下面 /vendor 项目依赖的其他第三方库，使用 glide 工具来管理依赖 /api 协议文件，Swagger/thrift/protobuf 等 /web web服务所需要的静态文件 /configs 配置文件 /init 服务启停脚本 /scripts 其他一些脚本，编译、安装、测试、分析等等 /build 持续集成目录 云 (AMI), 容器 (Docker), 操作系统 (deb, rpm, pkg)等的包配置和脚本放到 /build/package/ 目录 /deployments 部署相关的配置文件和模板 /test 其他测试目录，功能测试，性能测试等 /docs 设计文档 /tools 常用的工具和脚本，可以引用 /internal 或者 /pkg 里面的库 /examples 应用程序或者公共库使用的一些例子 /assets 其他一些依赖的静态资源 https://www.jianshu.com/p/1c47d99f33ed

舱壁模式 什么是舱壁模式 舱壁模式 (Bulkhead) 隔离了每个工作负载或服务的关键资源，如连接池、内存和CPU。 使用舱壁避免了单个工作负载 (或服务) 消耗掉所有资源，从而导致其他服务出现故障的场景。 这种模式主要是通过防止由一个服务引起的级联故障来增加系统的弹性。 工业中使用舱壁将船舶划分为几个部分，以便在船体破坏的情况下，可以将船舶各个部件密封起来。舱壁的概念在软件开发中可以被应用在隔离资源上。通过应用舱壁模式，我们可以保护有限的资源不被耗尽。例如，对于一个有连接数限制的数据库实例来说，如果我们有两种连接它的操作，我们采用可以采用两个连接池的方式进行连接，来代替仅采用一个共享连接池的方式。由于这种客户端与资源进行了隔离，超时或过度使用池的操作页不会使其他操作失败。泰坦尼克号沉没的主要原因之一是其舱壁设计失败，水可以通过上面的甲板倒在舱壁的顶部，导致整个船体淹没。 作者: AskHarries 链接: https://juejin.im/post/5b32d3e36fb9a00e952ce899 来源: 掘金 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

srt,ass,ssa 字幕 srt,ass,ssa三种字幕的区别 ass > ssa > srt 流行的字幕一共有三种就是 ass、ssa、srt。 srt 全称是 SubRip Text, 最常见的文本字幕，制作起来简单，时间代码+字幕。 ssa 全称是 S Station Alpha, 功能上比src更强大支持各种颜色、字体等特效。 ass 全称是 Advanced SubStation Alpha, 包含ssa所有的功能并在ssa原有功能的基础上还进行了扩展。 视觉角度上讲ssa和ass视觉效果更好一些。 扩展: 字幕常见的标识 chs、cht、GB、Big5、eng。 chs是Chinese Simplified的缩写，表示简体中文。 cht是Chinese Traditional的缩写，表示繁体中文。 GB既"国标"的汉语拼音的缩写，中华人民共和国国家标准的意思，简体中文。 Big5是在台湾和香港等地广为使用的计算机汉字编码方案，繁体中文。 eng是English的简写，也就是说表示英文。 https://blog.csdn.net/wuhao91/article/details/50454051

outlook 导出邮件, 备份, archive, import, export 菜单: File > Options > Advanced > Export > Export to a file > 选择 Outlook Data File (.pst) > Next 展开树状列表，选择要备份的目录, 勾选 “include subfolders” 点击 Next 选择存放导出的 pst 文件的目标目录 (Save exported file as:) 点击 Finish 不设置 密码 点击 确定 等进度条走完 ( 备份文件比较小的时候可能看不到进度条 ) 在 outlook 里删除已经备份的目录. 导入 解压 导入 File> Open & Export> Open Outlook Data File 然后到 Outlook 窗口左侧的树状菜单底部的 Outlook Data File 下面就能找到了. ...

alpine basic alpine mirror vi /etc/apk/repositories # b. 将里面 dl-cdn.alpinelinux.org 的 改成 mirrors.aliyun.com ; 保存退出即可 sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories # alpine install telnet apk update apk add busybox-extras busybox-extras telnet localhost 6900 apk add drill apk add tcpdump apk add curl 明明镜像中有对应的二进制文件，但是执行时却提示 not found 或 no such file¶ 有时可能会遇到明明镜像中存在相应的二进制文件，但是执行对应的二进制文件时却提示 not found 或 no such file 错误，类似下面这样: ls /usr/bin/grep /usr/bin/grep /usr/bin/grep /bin/sh: /usr/bin/grep: not found 常见原因：该二进制文件是使用动态链接方式编译了一个使用了 GLIBC 库的程序生成的，但是 alpne 镜像中没有 GLIBC 库而是用的 MUSL LIBC 库，这样就会导致该二进制文件无法被执行。 ...

Scrum的5个核心价值 什么是5个Scrum的核心价值？ 什么是5个Scrum的核心价值？ (英文原版) (日本語版) Scrum是敏捷软件开发的一个非常流行和众所周知的框架。几年前，Scrum在框架中添加了5个值，团队中的每个成员都使用它来指导他的决策。并不是很多人都知道并理解这些价值观，但它们对于scrum的成功实施至关重要，值得在这里详细阐述它们的含义。 Scrum值 那么Scrum值是什么？下图描绘了5个值: 五个Scrum值 (来源: Scrum.org – Scrum价值海报) 勇气 在Scrum团队成员有勇气做正确的事和棘手的问题的工作。团队成员在做正确的事情和承担明智的风险时相互支持，以便我们可以沿着我们的伟大道路学习和改进，包括: 承认没有人是完美的 提供撤消版本的产品 共享所有可能的信息以帮助团队和组织 承认没有完美的要求捕捉和面临快速变化是现实 焦点 每个人都关注Sprint的工作和Scrum团队的目标。当我们处理复杂性和不可预测性时，重点是必要的，以便做出任何有意义的事情。因为我们一次只关注一些事情，所以我们会尽快提供最有价值的物品。Scrum框架包含有助于促进关注的元素。 团队应该至少在每个Sprint结束时专注于"完成增量"。 每个Scrum 角色都有一个独特的问责制，可以帮助个人知道要关注什么作为他们的优先事项。这最终有助于团队成果。 Scrum团队专注于Sprint目标，以指导团队提供什么 该产品积压是一个优先顺序，以及创建专注于下一个是什么做的最重要的事情。 时间限制的冲刺事件创造了一种紧迫感，并帮助我们专注于事件的目的。 在Scrum的事件和文物帮助建立重点检查的进展和新的信息，让球队能够以足够频繁的间隔适应。 承诺 Scrum团队成员必须致力于成功，并愿意创建切合实际的目标并坚持下去。每个Scrum角色都致力于团队的成功，而不仅仅是关注我们的个人成就，通过以下方式创建信任，高效解决问题和高团队标准的环境: 该产品负责人演示了通过进行最佳决策，以优化产品的价值，而不是简单地试图取悦每一个利益相关者的承诺。 在Scrum Master的通过坚持Scrum的框架，这意味着我们不延长冲刺或其他时间盒压力去下演示的承诺"完成"。 在Scrum Master的证明通过删除Scrum团队不能自行解决的障碍，而不是容忍在组织现状的承诺。 该开发团队通过创建一个符合他们的"做，“不是东西，几乎是做了定义的增量演示的承诺。 尊重 作为自组织团队，我们不能没有彼此尊重，因此我们将为所有人培养一个参与，富有成效和人性化的环境。Scrum框架包含有助于促进尊重的元素。 整个Scrum团队参加Sprint Planning，Sprint Review和Sprint Retrospective。这促进了对每个角色，责任和不同观点的尊重。 开发团队是跨职能的，这意味着它具有提供"完成"产品增量所需的所有技能。这促进了对每个人的经验，技能和想法的尊重。这也促进了学习和成长。 该代办冲刺是由开发团队拥有。由于他们是做这项工作的人，他们决定他们在Sprint中可以做多少以及如何做这项工作。这表明了对他们的知识和技能的尊重，以及对以可持续的速度工作的尊重。 通过仅审查Sprint评审中的"完成"产品，我们为我们的真实进步带来了透明度。这体现了对利益相关者的尊重。 产品负责人寻求利益相关者的意见，合作并为利益相关者设定切合实际的期望。这是对利益相关者的尊重的另一种表现。 Scrum Master的重点是Scrum团队的健康状况以及Scrum的有效使用。担任教学，促进和辅导的角色表明了对人员和团队及其成长能力的尊重。 Scrum专注于提供价值，通过不花钱购买低价值功能或可能永远不会使用的东西来表达对我们组织的尊重。 在Sprint结束时具有潜在可释放的增量，通过不强迫更多投资实现价值，表明了对我们组织的尊重。它使组织可以灵活地做出投资决策。 透明度 Scrum的经验主义要求透明，开放，通过了解我们的工作安排，我们的进步，我们的学习和我们的问题。团队应该开放，跨学科和技能进行协作，与利益相关者和更广泛的环境协作，分享反馈和相互学习。Scrum框架包含有助于促进开放性的元素。 将Sprint限制在30天或更短时间，可以根据新信息促进对改变方向的开放性。 Sprint目标是固定的并提供指导，但是根据开发团队正在学习的内容，满足Sprint目标的计划是可以改变的。 透明的产品待办事项向我们的利益相关者展示了对产品计划内容 (以及未计划的内容) 以及下一步可能的内容的开放性。 Sprint Retrospective专注于持续改进我们团队的互动，流程和工具，这使我们能够开放反馈，反思和改变我们的工作方式。 Sprint Review展示了与利益相关者分享进展的开放性，以及对他们的反馈和协作的开放性。

chrome extension content script, 只能访问 dom, 不能访问页面 js 变量和函数 Injected Script, 被插入到页面里的 js 代码 chrome://extensions puzzle button: chrome extension 图标后面的拼图按钮 develop chrome extension doc https://developer.chrome.com/docs/extensions/mv3/ javascript web api: https://developer.mozilla.org/en-US/docs/Web/API chrome api: https://developer.mozilla.org/en-US/docs/Web/API html: https://web.dev/learn/html/ css: https://web.dev/learn/css/ javascript: https://developer.mozilla.org/en-US/docs/Learn/JavaScript chrome extension development overview: https://developer.chrome.com/docs/extensions/mv3/devguide/ chrome extension 的构成 The manifest, manifest.json, 唯一一个必须要存在于 extension 根目录的文件 The service worker, service worker 监听 chrome 的各种事件, 可以调用 Chrome api, 但是不能直接操作页面内容 Content scripts: content script 可以直接在页面中执行 js 代码, 可以直接操作 DOM, 还可以跟 service worker 通信 The popup and other pages crxjs, react https://crxjs.dev/vite-plugin ...