时间之旅

技术相关 Python学习指南 Linux实践指南 前端 数据库 云原生实践指南 书影音 书单 影单 工具 office+project+visio2019激活 广告过滤规则

转载自左耳朵耗子的话 昨天，一整天都不开心。朋友圈里，几乎每翻一屏，都能看到有人在转左耳朵耗子离世的消息。作为一名创造者，左耳朵耗子为这个世界留下了很多作品，比如他的博客 CoolShell、他的极客时间专栏左耳听风，以及他的公司 MegaEase。感慨世事无常的同时，我也在回忆，左耳朵耗子讲过的那些有分量的话。 对于生者来说，左耳朵耗子是一个好榜样。他近乎偏执地追求技术驱动创新，他敢于挑战权威、从不盲从，他知世故而不世故的作风，将会永远留在我们心里。 我司的池老师和陈皓是多年老友，他 15 号凌晨就得知了这个噩耗，中午他写了一篇悼文放到了墨问便签上，看得让人泪目。 沉痛缅怀好友左耳朵耗子 今天早上来了公司，我猛然想起两年前，和他的连麦直播。那一次，他完整地阐述了他为什么创业，他的梦想是什么，他这辈子想做件什么事。记得当时弹幕区里有用户说，这场直播，是自己人生觉醒的分水岭，意义非凡。我赶忙找到了那期直播的视频（差点丢了），然后约同事和朋友一起，完成了内容精编。 这是左耳朵耗子给我们留下的精神遗产。我们在怀念他的时候，不妨去理解和实践他的人生观和做事观吧。以下，是具体内容。 创业为 ...

ping 0On Linux： 1234$ ping 0PING 0 (127.0.0.1) 56(84) bytes of data.64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.075 ms64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.065 ms On Mac： 1234$ ping 0PING 0 (0.0.0.0): 56 data bytesping: sendto: No route to hostping: sendto: No route to host 在这里，它翻译为一个空路由0.0.0.0。 0 是可选的1234$ ping 127.1PING 127.1 (127.0.0.1) 56(84) bytes of data.64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.079 ms64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.065 ms 需 ...

📖参考： Nginx如何限流 nginx documentation 概述流量限制(rate-limiting)，是 Nginx 中一个非常实用，却经常被错误理解和错误配置的功能。我们可以用来限制用户在给定时间内 HTTP 请求的数量。 流量限制可以用作安全目的，比如可以减慢暴力密码破解的速率。通过将传入请求的速率限制为真实用户的典型值，并标识目标URL地址(通过日志)，还可以用来抵御 DDOS 攻击。更常见的情况，该功能被用来保护上游应用服务器不被同时太多用户请求所压垮。 如何限流Nginx 的”流量限制”使用漏桶算法(leaky bucket algorithm)，该算法在通讯和分组交换计算机网络中广泛使用，用以处理带宽有限时的突发情况。就好比，一个桶口在倒水，桶底在漏水的水桶。如果桶口倒水的速率大于桶底的漏水速率，桶里面的水将会溢出；同样，在请求处理方面，水代表来自客户端的请求，水桶代表根据”先进先出调度算法”(FIFO)等待被处理的请求队列，桶底漏出的水代表离开缓冲区被服务器处理的请求，桶口溢出的水代表被丢弃和不被处理的请求。 限流使用的模块Nginx 的 limit ...

开源地址：onceupon/Bash-Oneliner: A collection of handy Bash One-Liners and terminal tricks for data processing and Linux system maintenance. Terminal TricksUsing Ctrl keys12345678910111213141516Ctrl + n : same as Down arrow.Ctrl + p : same as Up arrow.Ctrl + r : begins a backward search through command history.(keep pressing Ctrl + r to move backward)Ctrl + s : to stop output to terminal.Ctrl + q : to resume output to terminal after Ctrl + s.Ctrl + a : move to the beginning of line.Ctrl + e ...

之前做了RDS监控，由于 RDS 实例数量增多，手动添加的方式已经不够效率，故改为 LLD(Low-level discovery) 方式做监控。 什么是 LLDLLD(Low-level discovery)，即低级发现，提供了一种在计算机上为不同实体自动创建监控项，触发器和图形的方法。例如，Zabbix 可以在你的机器上自动开始监控文件系统或网络接口，而无需为每个文件系统或网络接口手动创建监控项。此外，可以配置 Zabbix 根据定期执行发现后的得到实际结果，来移除不需要的监控。 用户可以自己定义发现类型，只要它们遵循特定的 JSON 协议。 采集数据脚本调用阿里云 Api，采集 RDS 相关数据，相关配置可参考之前的文章，采集脚本略。 需要将 Api 返回的数据处理，将字段修改为 {#MACRO} 形式的 LLD 宏，最后生成 json 格式的数据： 例如： 12345678910[{ "{#DBINSTANCEID}": "rr-XXX", "{#DBNAME&# ...

电脑连接有线网卡的情况下，默认不会主动连wifi。特殊情况需要同时连无线wifi，每次得手动去连wifi，然而网上大部分教程都是教你不连有线网卡的情况下自动连wifi，并不能解决当前情况。 解决方法： Win键+R打开，输入regedit，打开注册表编辑器。 找到以下路径：HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WcmSvc\GroupPolicy。 在GoupPolicy下，右侧空白区域，鼠标右键–>新建–>DWORD(32位)值。 把这个新建的DWORD(32位)改名为fMinimizeConnections。 关闭注册表编辑器，重启电脑。

参考：Volumes | Kubernetes、Persistent Volumes | Kubernetes、Kubernetes 基础入门实战 简单来说，存储卷是定义在Pod资源之上可被其内部的所有容器挂载的共享目录，该目录关联至宿主机或某外部的存储设备之上的存储空间，可由Pod内的多个容器同时挂载使用。Pod存储卷独立于容器自身的文件系统，因而也独立于容器的生命周期，它存储的数据可于容器重启或重建后继续使用。 存储卷并非Kubernetes上一种独立的API资源类型，它隶属于Pod资源，且与所属的特定Pod对象有着相同的生命周期。 PV（PersistentVolume）与PVC（PersistentVolumeClaim）就是在用户与存储服务之间添加的一个中间层，管理员事先根据PV支持的存储卷插件及适配的存储方案（目标存储系统）细节定义好可以支撑存储卷的底层存储空间，而后由用户通过PVC声明要使用的存储特性来绑定符合条件的最佳PV定义存储卷，从而实现存储系统的使用与管理职能的解耦，大大简化了用户使用存储的方式。 前置知识 Kubernetes：Pod总结(一) Kubern ...

参考：Ingress | Kubernetes、《Kubernetes进阶实战》、《Kubernetes网络权威指南 》 何谓Ingress？从字面意思解读，就是入站流量。Kubernetes的Ingress资源对象是指授权入站连接到达集群内服务的规则集合。 我们知道，Kubernetes上的NodePort和LoadBalancer类型的Service资源能够把集群内部服务暴露给集群外部客户端访问，但两个负载均衡跃点(路由)必然产生更大的网络延迟，且无疑会大大增加组织在使用云服务方面的费用开销。 因此，Kubernetes为这种需求提供了一种更为高级的流量管理约束方式，尤其是对HTTP/HTTPS协议的约束。Kubernetes使用Ingress控制器作为统一的流量入口，管理内部各种必要的服务，并通过Ingress这一API资源来描述如何区分流量以及内部的路由逻辑。有了Ingress和Ingress控制器，我们就可通过定义路由流量的规则来完成服务发布，而无须创建一堆NodePort或LoadBalancer类型的Service，而且流量也会由Ingress控制器直接到达 ...

参考：Service | Kubernetes、《Kubernetes进阶实战》 有了 Workload，我们可以方便地管理多实例的应用，但是要想能够方便地访问应用，我们还需要一个类似于 负载均衡 的资源来分发请求，在 kubernetes 中，有两个资源负责这个功能，分别是 Service 以及 Ingress。其中 Service 主要负责集群内部的访问，而 Ingress 主要负责来自集群外部的访问。 Kubernetes Service从逻辑上代表了一组Pod(通常称为微服务)，具体是哪些Pod则是由label来挑选的(selector)。Service有自己的IP，而且这个IP是不变的。客户端只需要访问Service的IP，Kubernetes则负责建立和维护Service与Pod的映射关系。无论后端Pod如何变化，对客户端不会有任何影响，因为Service没有变。 举个例子，考虑一个图片处理后端，它运行了 3 个副本。这些副本是可互换的 —— 前端不需要关心它们调用了哪个后端副本。 然而组成这一组后端程序的 Pod 实际上可能会发生变化， 前端客户端不应该也没必要知道， ...