mac清理dns缓存

MacOS 版本 使用的命令
macOS 12 (Monterey) sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
macOS 11 (Big Sur) sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
macOS 10.15 (Catalina) sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
macOS 10.14 (Mojave) sudo killall -HUP mDNSResponder
macOS 10.13 (High Sierra) sudo killall -HUP mDNSResponder
macOS 10.12 (Sierra) sudo killall -HUP mDNSResponder
OS X 10.11 (El Capitan) sudo killall -HUP mDNSResponder
OS X 10.10 (Yosemite) sudo discoveryutil udnsflushcaches
OS X 10.9 (Mavericks) sudo killall -HUP mDNSResponder
OS X 10.8 (Mountain Lion) sudo killall -HUP mDNSResponder
Mac OS X 10.7 (Lion) sudo killall -HUP mDNSResponder
Mac OS X 10.6 (Snow Leopard) sudo dscacheutil -flushcache
Mac OS X 10.5 (Leopard) sudo lookupd -flushcache
Mac OS X 10.4 (Tiger) lookupd -flushcache

READ MORE

负载均衡

  1. 随机、加权随机
  2. 哈希(源地址(ip)哈希、url哈希、一致性哈希)
  3. 轮询、加权轮询
  4. 最小连接(最小活跃数)

所谓四层即运输层，就是基于 IP + 端口的负载均衡；
七层即应用层，就是基于 URL 等应用层信息的负载均衡；
同理，还有基于 MAC 地址的二层负载均衡和基于 IP 地址的三层负载均衡。

二层负载均衡会通过一个虚拟 MAC 地址接收请求，然后再分配到真实的 MAC 地址；
三层负载均衡会通过一个虚拟 IP 地址接收请求，然后再分配到真实的 IP 地址；
四层通过虚拟 IP + 端口接收请求，然后再分配到真实的服务器；
七层通过虚拟的 URL 或主机名接收请求，然后再分配到真实的服务器。
所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。
比如四层的负载均衡，就是通过发布三层的 IP 地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，
对需要处理的流量进行 NAT 处理，转发至后台服务器，并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的，
后续这个连接的所有流量都同样转发到同一台服务器处理。
七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征， 比如同一个 Web 服务器的负载均衡，除了根据 VIP 加 80 端口辨别是否需要处理的流量， 还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。

  1. 二层负载均衡（mac）
    根据OSI模型分的二层负载，一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应）
  2. 三层负载均衡（ip）
    一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应）
  3. 四层负载均衡（tcp）
    在三次负载均衡的基础上，用ip+port接收请求，再转发到对应的机器。
  4. 七层负载均衡（http）
    根据虚拟的url或IP，主机名接收请求，再转向相应的处理服务器）。

引用:

linux负载均衡总结性说明（四层负载/七层负载）

四层、七层负载均衡的区别

READ MORE

git文件权限

Git中如何对文件权限做版本控制的？

在开发中，经常会使用git来做版本管理，我们主要是用来管理文件的内容，今天首次发现git还可以记录文件的权限修改，特地记录下。

比如，如下这个文件，没有修改前权限是644：

$ ll-rw-r–r– 1 staff staff 932B Jan 13 11:01 webpack.mix.js

现在，我们修改成755：

$ chmod 755 webpack.mix.js-rwxr-xr-x 1 staff staff 932B Jan 13 11:01 webpack.mix.js

查看git记录，里面已经记录了：

$ git status On branch mainYour branch is up to date with ‘origin/main’. Changes not staged for commit: (use “git add <file>…” to update what will be committed) (use “git restore <file>…” to discard changes in working directory) modified: .idea/workspace.xml # 该文件已经被修改 modified: webpack.mix.js no changes added to commit (use “git add” and/or “git commit -a”)

…
READ MORE

解决PHP处理图片时内存占用过高问题

https://www.cnblogs.com/68xi/p/10993602.html

用过GD库的同学可能都知道，使用imagecreatetruecolor()函数创建一个真彩色的画布是第一步。但是，如果画布的宽高超过平常的宽高，会带来极大的内存消耗。比如，一个9600×4800的画布，会带来190M的内存消耗。这时，如果服务器的free空间过小，就会导致内存耗尽，出现各种报错。本文旨在提供优化服务器时对大图片的处理方法。

   首先，说下业务场景。我要对用户上传的图片进行裁剪，变成我想要的宽高比。注意，是2:1这种宽高比。 因为用的服务器内存总共只有512M,处理小图片时还好，但是一旦接触到4M以上的图片文件，内存耗尽就成了一个block的点。它会引发nginx报502的错误，因为nginx无法从php-fpm那里获取到相应的值。报错日志：a client request body is buffered to a temporary file。3119133 recv() failed (104: Connection reset by peer) while reading response header from upstream 这里可以提供下，我使用GD库对图片进行处理时的内存占用情况的日志：
1 获取大小内存-1 376.12 kb
2 获取大小内存 4.98 mb
3 #这里使用了imagecreatetruecolor
4 获取大小内存2 192.53 mb 图片width:9600height4800
5 获取大小内存3 287.92 mb
6 获取大小内存4 287.92 mb
7 获取大小内存5 287.92 mb
8 获取大小内存6 100.38 mb
9 获取大小内存7 104.48 mb
10 #这里实行了最后一步，释放内存 获取大小内存+1 376.21 kb

　　可以看到，很明显的内存占用，关于图片宽高对内存的影响，网上有个公式：

…
READ MORE

markdown自动添加头部信息 

# 给content目录下的所有文件添加头部信息

import os
import time

def add_header(file_name):
    datetime = time.strftime("%Y-%m-%dT%H:%M:%S%z", time.localtime())
    with open(file_name, "r+", encoding='utf-8') as f:
        # 文件名去掉路径
        file_name = os.path.basename(file_name)
        # 异常处理，防止文件内容为空
        try:
            content = f.read()
        except UnicodeDecodeError:
            print(file_name + "文件内容为空")
            content = ""
        f.seek(0, 0)
        f.write("---\ndate: " + datetime + "\ntitle: \"" + file_name[:-3] + "\"\n---\n\n" + content)

def delete_header(file_name):
    with open(file_name, 'r+', encoding='utf-8', errors='ignore') as f:
        #删除前5行
        for i in range(5):
            f.readline()
        # 读取剩余内容
        content = f.read()
        f.seek(0, 0)
        f.write(content)

def recursive_add_header(dir_name):
    for file_name in os.listdir(dir_name):
        if file_name.endswith(".md"):
            add_header(os.path.join(dir_name, file_name))
        elif os.path.isdir(os.path.join(dir_name, file_name)):
            recursive_add_header(os.path.join(dir_name, file_name))

def recursive_delete_header(dir_name):
    for file_name in os.listdir(dir_name):
        if file_name.endswith(".md"):
            delete_header(os.path.join(dir_name, file_name))
        elif os.path.isdir(os.path.join(dir_name, file_name)):
            recursive_delete_header(os.path.join(dir_name, file_name))

if __name__ == "__main__":
    recursive_add_header("content")

READ MORE