SQL Command

mysql数据库权限位

下表说明了可用于GRANT和REVOKE语句的所有可用权限：

HTTP Status Codes

1xx - 信息

这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于HTTP/1.0协议中没有定义任何1xx状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送1xx响应。这些状态码代表的响应都是信息性的，标示客户应该采取的其他行动。

2xx - 成功

这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。

VPN技术对比

目前，VPN技术主要包括：PPTP、L2TP/IPSec、SSLVPN、OpenVPN和WebVPN几种，笔者通过表1对五种VPN进行对比。

PPTP、L2TP和IPSec

对网络要求很高，当运营商的网络存在地址转换设备时，将无法正常连接。目前，最常用的VPN技术主要为SSL VPN和WebVPN。

WebVPN

提供基于Web的内网应用访问控制，允许授权用户访问只对内网开放的Web应用，实现类似VPN的功能。区别于传统VPN技术，WebVPN无需用户做任何配置或安装客户端软件及浏览器插件，直接在网页上通过身份验证即可进入内网应用，大大降低了使用门槛，提升了用户体验感。但是，WebVPN只适用于采用B/S架构的Web浏览器的应用，而对C/S架构的客户端和移动端的应用无法支持。

SSL VPN

是以SSL协议为安全基础的VPN远程接入技术。远程用户使用SSLVPN可以安全方便地接入内网，访问内网资源；无需安装额外软件，直接使用浏览器访问内网Web资源，也可以通过安装浏览器插件，访问其他非Web资源；SSL VPN既支持全局流量，也支持局部流量，根据不同用户的身份，分配不同的访问权限，实现精细控制。

OpenVPN

作为一个开源软件，就是一个典型的SSL VPN应用，使用的是工业标准的SSL/TLS协议。OpenVPN不是一个基于Web代理的应用，也不是基于浏览器访问，而是需要安装专门的客户端，其客户端可以支持当前所有主流终端类型。

参考

https://www.sohu.com/a/594884085_100189681

静脉曲张症状与病因

静脉曲张诊断与治疗

硬化疗法

压力袜

参考

静脉曲张症状与病因
静脉曲张诊断与治疗
硬化疗法
静脉热消融
协和专家：别再给血管添堵了
sigvaris

视频讲解参考

检查

检查越充分，医生对于病情的分析也越准确，此步骤必不可少，并且患者及其家属害怕可能出现的误诊，会选择到更权威的医院再做其中的一些项目以充分论证其准确性。

日常检查

CT, B超，查血、大小便等

病理分析

用以检查机体器官、组织或细胞中的病理改变的病理形态学方法。为探讨器官、组织或细胞所发生的疾病过程，可采用某种病理形态学检查的方法，检查他们所发生的病变 ，探讨病变产生的原因、发病机理、病变的发生发展过程，最后做出病理诊断。病理形态学的检查方法，首先观察大体标本的病理改变，然后切取一定大小的病变组织，用病理组织学方法制成病理切片，用显微镜进一步检查病变。

对于癌症，我们都知道病理学的重要性，因为病理诊断更是决定了疾病的分类与医生治疗的方针，但是当然病理报告因为一些意外的情况导致病理报告有误，像是切片检体太小，根本无从判断，或者根本没有切到病诏等等因素，导致判断错误。因此在评估病人的状况时候，必须考虑到病史、理学检查、血液生化检查、影像学检查等等做个综合判断的评估。

病理切片分析一般在5天~10天左右出结果。

病理切片

取一定大小的病变组织，用病理组织学方法制成病理切片〔通常将病变组织包埋在石蜡块里，用切片机切成薄片，再用苏木精－伊红(H-E)染色〕，用显微镜进一步检查病变。病变的发生发展过程，最后作出病理诊断。

1. 组织固定（与组织体积正相关，一般24-48小时）
2. 组织脱水（最佳脱水时间主要取决于组织的大小和类型来决定）
3. 组织包埋
4. 组织切片及捞片
5. 烤片（45分钟~1小时）
6. 脱蜡及

#定义Nginx运行的用户和用户组
user www www; 
#nginx进程数，通常设置成和cpu的数量相等
worker_processes 4; 
#全局错误日志定义类型，[debug | info | notice | warn | error | crit]
#error_log  /data/nginx/logs/error.log;
#error_log  /data/nginx/logs/error.log  notice;
#日志文件存放路径 access_log path [format [buffer=size | off]]
access_log /data/nginx/logs/lazyegg.com/web/access.log combinedio;
#进程pid文件
#pid        logs/nginx.pid;
#指定进程可以打开的最大描述符：数目
#工作模式与连接数上限
##这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit -n 的值保持一致。
#这是因为nginx调度时分配请求到进程并不是那么的均衡，所以假如填写10240，总并发量达到3-4万时就有进程可能超过10240了，这时会返回502错误。
worker_rlimit_nofile 65535;
#################################  events  ###############################
events {
    #参考事件模型，use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型
    use epoll
    #单个进程最大连接数（最大连接数=连接数+进程数）
    worker_connections  1024;
    #keepalive 超时时间
    keepalive_timeout 60;
    #客户端请求头部的缓冲区大小。
    client_header_buffer_siz

CoreOS 默认 logrotate问题

默认的logrotate是daily的，在/usr/下是无法更改的，故只能停止了默认logrotate timer，然后新建新的timer来改变logrotate的周期

systemctl stop logrotate.timer

$ cat /usr/lib/systemd/system/logrotate.service 
[Unit]
Description=Rotate and Compress System Logs
[Service]
ExecStart=/usr/sbin/logrotate /usr/share/logrotate/logrotate.conf

$ cat /usr/lib/systemd/system/logrotate.timer
[Unit]
Description=Daily Log Rotation
[Timer]
OnCalendar=daily
AccuracySec=1h
Persistent=true

演练配置

logrotate -d /etc/logrotate.d/test

$ logrotate --help
Usage: logrotate [OPTION...] <configfile>
  -d, --debug               Don't do anything, just test (implies -v)
  -f, --force               Force file rotation
  -m, --mail=command        Command to send mail (instead of `/bin/mail')
  -s, --state=statefile     Path of state file
  -v, --verbose            

报错

$ go mod  tidy
fatal: unable to access 'https://gogs.xxx.com/xxx/xxx.git/': Peer's Certificate issuer is not recognized

原因

gogs 实际用的yyy.so，通过nginx做了转发访问xxx.com会转发到yyy.so，但是用户在GET页面时yyy.so会被替换成xxx.com（实际内容是未变的，只是页面返回被修改了），猜测可能是转发上有某些问题

server {
    listen 80;
    listen 443 ssl;
    server_name gogs.xxx.com; ## 域名，根据自己实际情况填写
    error_log /data/logs/nginx/gogs.xxx.com/error.log;
    access_log /data/logs/nginx/gogs.xxx.com/access.log;
    client_max_body_size 50m;
    ssl_certificate "tls/xxx.com.pem";
    ssl_certificate_key "tls/xxx.com.key"; 
    location / {
        #set $vhost "gogs.yyy.so";
        proxy_set_header   Host  $host; 
        add_header Access-Control-Allow-Origin *;
        add_header Access-Control-Allow-Headers X-Requested-With;
        add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
        proxy_pass http://127.0.0.1:3000/;  ## gogs默认服务端口为3000
        #proxy_redirect ~^https://([^:]

Consul简述

Consul是服务网格（service mesh）的一种解决方案，Consul是有服务发现，配置和分段 功能的全功能控制平面。这些功能可以根据需要单独使用，也可以一起使用以构建完整的服务网格。Consul需要一个数据平面，并支持代理和本机集成模型。Consul附带了一个简单的内置代理，因此开箱即用，但也支持Envoy等第三方代理集成。
Consul其实解决了运行微服务和云原生基础架构的网络和安全挑战。Consul提供了一种云原生的软件驱动路由和分段方法。它还带来了其他好处，比如故障处理，重试和网络可观察。
上面说到了服务网格和数据平面，服务网格通常是和微服务在一起说的服务网格，数据平面很好理解就是软件和服务架构中处理数据请求的那层，相比之下，控制平面就是配置和关闭数据平面的软件部分，这里Consul就起到了控制平面的作用。

Consul的主要特点有以下：

服务发现

Consul的客户端可以注册服务，例如api或mysql，客户端可以使用Consul来发现已注册的服务。使用DNS或HTTP，应用程序可以轻松找到它们依赖的服务。

健康检测

Consul客户端可以提供任何数量的运行状况检查，这些检查可以与给定服务（“ Web服务器是否返回200 OK”）或本地节点（“内存利用率低于90％”）相关。你可以使用此信息来监视群集的运行状况，服务发现组件可以使用这些信息将流量从不正常的主机转移走。

KV存储

你应用程序可以将Consul的分层 键/值 存储用于多种目的，不限于 动态配置，功能标记，协调，集群leader选举等等。Consul提供的简单HTTP API使其非常易于使用。

安全的服务通信

Consul可以为服务生成和分发TLS证书然后建立相互的TLS连接。意图 用于定义允许哪些服务进行通信。可以实时更改意图轻松管理服务分段，而不使用复杂的网络拓扑和静态防火墙规则。

多数据中心

Consul开箱即用地支持多个数据中心。这意味着Consul的用户不必担心会构建其他抽象层以扩展到多个区域
Consul的设计对DevOps社区和应用程序开发人员非常友好，使其非常适合现代，灵活的基础架构。

1.0 前言

　　话说有一名意大利程序员，在 2004 年到 2006 年间主要做嵌入式工作，之后接触了 Web，2007 年和朋友共同创建了一个网站，并为了解决这个网站的负载问题（为了避免 MySQL 的低性能），于是亲自定做一个数据库，并于 2009 年开发完成，这个就是 Redis。这个意大利程序员就是 Salvatore Sanfilippo 江湖人称 Redis 之父，大家更习惯称呼他 Antirez。

　　Redis 技术越来越火爆，其超高的性能，简洁轻量的设计，易上手，分布式架构的支持，在缓存等领域出色的表现造就了它现在的地位。

　　官方的 Benchmark 数据：测试完成了 50 个并发执行 10W 个请求。设置和获取的值是一个 256 字节字符串。

　　结果：读的速度是 110000次/s，写的速度是 81000次/s。值得注意的是，该测试结果还是早些年旧机器上的测试结果。如果与今天的机器设备相比，预估可能是以下结果的两倍。
　　

$ redis-benchmark -n 100000
====== SET ======
  100007 requests completed in 0.88 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
58.50% <= 0 milliseconds
99.17% <= 1 milliseconds
99.58% <= 2 milliseconds
99.85% <= 3 milliseconds
99.90% <= 6 milliseconds
100.00% <= 9 milliseconds
114293.71 requests per sec