元旦假期，无所事事，只能在家里刷刷b站，打打LOL，回想起这半年工作上的事项，也是挺唏嘘的，996已成常态，好在项目最终验收，至少几个月努力没有白费。
突然想起将近1年多没写文章了，主要是工作行业上有些变动，新的工作涉及一些新的领域 - git代码研发管理，所以在这块上投入了大量的时间进行行业、技术的研究。

废话不多说，直接进入重点。

近半年来，除了负责gitee主线正常的迭代外，还插手交付几家银行类的私有云大客户的事项，当时交付后不少用户频繁遇到此问题，虽然现象千奇百怪，但是无非是错误的操作导致的代码丢失，作为研发人员，应该关注这一类误操作的普及和说明，所以输出一篇文章，作为组内内部分享，让大家都能处理好此类问题。

“这个PR合并之后，我们的这个分支代码就丢失了一部分，你们靠不靠谱啊？！？！？？”
“你们gitee怎么搞的！我们代码又莫名其妙丢了！”
“昨天代码提交之后，今天早上就看不到提交了，能帮我查查原因吗？”
“为什么bitbucket能看到冲突的代码，你们gitee看不到呢？”
“这些提交为什么出现在我们的发布分支上了，今晚我们要发版，麻烦查查”

每当收到这些反馈，我都非常紧张，紧张并不是因为Gitee真的有什么问题，而是在想怎么去跟用户去解释，怎么帮用户复现、处理问题。
有些私有云客户已经交付了将近一年，收到的此类反馈数不胜数，但是归根究底，造成这些现象的根源还是在于对Git的不熟悉，分支研发流程不规范，对自己git操作后的结果没有预期。其实这类丢失代码的情况，无外乎以下2种情况：

• 使用 Git 进行推送的时候进行了强推操作
• 不正确的Merge操作造成的文件版本回退

binlog

binlog用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。binlog是mysql的逻辑日志，并且由Server层进行记录，使用任何存储引擎的mysql数据库都会记录binlog日志。

逻辑日志：可以简单理解为记录的就是sql语句。

物理日志：记录的是数据页上哪个地址的数据修改成什么。

binlog是通过追加的方式进行写入的，可以通过max_binlog_size参数设置每个binlog文件的大小，当文件大小达到给定值之后，会生成新的文件来保存日志，所以它没有大小的限制。

使用场景

在实际应用中，binlog的主要使用场景有两个，分别是主从复制和数据恢复。

1. 主从复制：在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。
2. 数据恢复：通过使用mysqlbinlog工具来恢复数据。

编码不易，转载请注意出处！

为什么进行瘦身优化？

减少运维部署成本

现在都讲究快速构建、快速部署，在网络带宽有限的情况下，部署一个1G大小的镜像和100M的镜像带来的时间差距可能就是分钟级和秒级的差距。特别像我们这种公司的私有化服务一样，今天客户机器到公司了，明天市场运营部的人可能就要拉走到客户那边去了，留给我们开发运维去部署和调试的时间少之又少，每个人的服务可能依赖或被依赖于其他人的服务，不能因为一个人还没部署好耽误了整体调试的时间，所以尽量要减少部署的时间，把更多的精力放到联调服务功能上面去。

Safari 没有开放代理 API，因为 macOS 可以很方便地设置系统级的全局代理，但是全局代理则会导致所有流量走代理服务器。

相比类似于 Chrome + SwitchyOmega (auto switch) 那种代理上网效果（国内正常，国外走代理），Safari 在代理上网方面的扩展程序实在乏善可陈，这篇文章所解决的需求就是在 macOS Safari 平台上实现 Chrome 的这种代理上网方式。

方法：

1）导出Chrome的PAC 文件

从 Chrome 的 SwitchyOmega 扩展程序中将 PAC 文件导出，记得选择自动切换模式下的 PAC 文件。

2）启动一个http server承载PAC文件

在本机存放 PAC 的目录下用 python 直接起HTTP 服务：

1

python -m http.server 11111

3）配置代理

系统偏好设置 👉🏻 网络 👉🏻 高级 👉🏻 代理 👉🏻 选择「自动代理配置」，URL填入刚才的PAC文件的下载地址:

1

http://127.0.0.1:11111/Safari.pac

Safari.pac就是刚才导出的PAC文件，目的是让系统能够找到PAC文件

4）进程服务自启动

可以用docker/supervisor/systemd类似的工具去管理进程，如果不想让本地维护http服务的话，可以在github中建个项目，把PAC文件上传，通过Github生成调用链接也是没问题的。

编码不易，转载请注意出处！

大原则：如果mysql优化器计算使用索引比全表扫描还慢，则不会使用索引，此原因会导致很多条件不走索引。

Mysql数据库优化的主要思路集中在3个方面

• sql语句优化
• 索引设计优化
• 数据库结构优化

1.sql语句优化

• 1）应尽量避免在 where 子句中使用!= 、<>、not in 、not exists、not like等反向操作符，否则将引擎放弃使用索引而进行全表扫描，通常情况下这些负向操作可以优化为in查看从而正常走索引查询。
• 2）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num=0。
• 3）很多时候用 exists 代替 in 是一个好的选择。
• 4）用Where子句替换HAVING 子句 因为HAVING 只会在检索出所有记录之后才对结果集进行过滤，而where语句可以针对索引树做查询。
• 5）索引字段不要做函数操作，会破坏b+ tree的有序性，优化器会放弃走索引。
• 6）基于最左前缀匹配原则，按照索引定义的字段顺序写sql。
• 7）建议只查需要的字段，比如覆盖索引可以有效避免回表，尽量不要使用 select *。
• 8）如果explain执行计划中没有走索引或不是最优的，可以用force index强制走某个索引。
• 9）如果使用的mysql版本支持开启索引条件下推，尽量开启它，因为它可以在使用联合索引时避免回表查询。

2.索引设计优化

• 1）在经常用在连接的列上建立索引，这些列主要是一些外键，可以加快连接的速度。
• 2）在经常需要根据范围进行搜索的列上创建索引，因为索引已经排好序了，其指定的范围是连续的。
• 3）对于那些在查询中很少使用的列不应该为其单独创建索引。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。实在想建立的话考虑一下能不能和其他字段建立联合索引。
• 4）对于一些区分度不是很好的列尽量不要建立索引，比如性别。因为在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。
• 5）对于一些可以在业务里面就可以生成唯一性的字段，不要对其建立唯一索引，因为唯一索引插入或者更新的时候不能利用到change_buffer，总要去读盘检查唯一性，效率很低。
• 6）如果某个列字符串特别长，可以考虑使用前缀索引，但要注意找到合适的前缀索引长度，否则会适得其反，比如邮件 @后面可能都一样，比较适合用前缀索引。
• 7）对于一些字符串前缀区分度不好的列时，建议使用倒序索引，目的是增加区分度，比如身份证号，前面区分度不大，但是不支持范围查询。

3.数据库结构优化

• 范式优化： 比如消除冗余（节省空间。。）
• 反范式优化：比如适当加冗余等（减少join），是否加冗余还是要看具体场景
• 水平、垂直分库分表。

编码不易，转载请注意出处！

前言

最近在学习golang，发现golang中的面向接口编程写起来真的太爽了，这个思想在go、java这种语言中是非常重要的，甚至所有编程语言都需要，毕竟程序的扩展性和可维护性谁都不能拒绝。

回看了下刚开始写python的一些代码，当时实现需求有个很明显的特点：

• 不同对象具有公共的行为能力，但具体每个对象的实现方式又各不相同。

说人话就是不同类具有相同的方法比如说create、update、delete等，但是具体实现逻辑又都不一样。

编码不易，转载请注意出处！

之前在看一些文章的时候看到过这两名词，当时还觉得好奇，因为从来没有听过，今天逛v站的时候又碰到了这个问题的讨论，各种说法都有，没有一个真正讲通的，本文就此问题来个深度探索。
先说结论，关于tcp粘包问题，从tcp流式设计上来看，它其实是一个伪命题。但是为什么会有那么多的开发者提出这样的问题？我们从 TCP 设计的特性可以不难看出，TCP 本就是面向连接、基于字节流且可靠的传输层通信协议，所以在 TCP 的这个层面来说并不存在包的这个概念，也就没有粘包这么一说了。那按照这么说，粘包问题还能凭空出现的？
在开始之前我们先达成一些共识：

1. 协议层中传输数据的基本单位统称为：Data Unit（数据单元）
2. 网络层 IP 协议传输的数据单元称为：Packet(包）
3. 传输层 TCP 协议传输的数据单元称为：Segment（段）
4. 传输层 UDP 协议传输的数据单元称为：Datagram（报）
5. 应用层传输的数据单元称为：Message（消息）

编码不易，转载请注意出处！

python多线程虽然有GIL管着，在IO密集型任务的时候，还是可以用的。
本文给出一个很简单的线程不安全的示例，说明一个事情：凡是共享的资源，都要自己加锁控制，不要以为python的每一行脚本都是原子操作，虽然python自定的确定义了一些原子操作，但是不要去依赖，如果哪一天python解释器修改了内部机制，你的代码就会崩溃；对于共享资源，无论有几个修改线程，加把锁更安全。

Ubuntu Server安装NVIDIA GPU驱动、CUDA和cuDNN

前言

最近公司业务涉及到了深度学习的一些知识，运维这边也买了一些硬件组了一台物理机。
刚开始接触深度学习的一些知识，就从这篇安装驱动文章入手吧。。。。。

Web资产指纹技术研究

Web-Based Fingerprinting【基于Web资产的指纹识别技术】

Web指纹识别的意义

[success] 攻击者根据Web指纹信息，使用对应的Web应用漏洞脚本进行攻击，造成了恶劣影响，且攻击案例逐年增加。因此，准确地识别Web服务器指纹信息，及时地了解Web服务可能存在的安全漏洞，并且对Web服务进行隐患排查和防护，具有重要的意义。

攻击者的角度

1. Web漏洞检测需要先识别Web服务器类型和版本，从而进行有针对性的漏洞挖掘和利用；
2. 有效信息的获取是实施攻击的先要条件。