0、问题描述
遇到了一个很奇怪的问题，微信发朋友圈，选择相册中的图片，识别不出来，发送提示失败。
图片是通过手机客户端生成后，保存在本地相册的。Android手机有这个问题，iOS没有。
Android保存逻辑：
0.0、传递给客户端的如果是url，客户端会获取url中的文件名，然后保存在本地。
0.1、传递给客户端的如果没有文件名，比如是base64格式的图片，客户端会生成一个文件名。
iOS保存逻辑：
0.2、客户端不管什么情况都会通过md5加密生成文件名，是系统本身的功能。（据说传了文件名对文件名md5, 没传文件名会有系统默认的算法）
把2年前整理的笔记放在这里，仅供查阅。
一、Redis安装
0、下载
在Redis官网的下载页面，我们只能下载最新的版本。
如果要查看下载历史版本，可以进入官网的这个页面http://download.redis.io/releases/(没有在官网找到这个链接的入口)
wget http://download.redis.io/releases/redis-5.0.5.tar.gz tar xzf redis-5.0.5.tar.gz
TCP是一个面向连接的协议，通信双方传输数据之前，必须建立连接。TCP建立连接和断开连接的策略，可以分不同层次的掌握，这里大致分4层。
一、通俗化的描述
建立TCP连接
服务器A和服务器B通信，建立连接比较好理解的比喻：
服务器A：你好服务器B，我是服务器A。
服务器B：你好服务器A，我是服务器B。
服务器A：服务器B，你好。
断开TCP连接
设定服务器A是主动结束方
服务器A：你好, 我的数据发送完毕了,我要进入准备断开的状态了。（此时它虽然不再发送数据了，但是可以接受数据）
服务器B：我知道了，我还没有发送完毕的，你等着吧。
服务器B：我也发送完毕了，可以断开连接了。（此时它也进入准备断开的状态）
服务器A：好的，那断开吧。
继续阅读
今天遇到了一个线上问题，具体是啥就不细说了。
思考了很久，重新梳理了下解决问题的思路：
0、出了问题，观察分析日志，是基本手段，是大家都知道的。此外，往往我们需要增加一些日志，打印出运行中的参数。观察新增日志的时候，尽量用真实的环境是触发生成日志，并且你的动作跟你的日志要对应起来，而不是模拟请求。比如客户端内H5页面的问题，用PC浏览器去模拟请求。
1、对于偶现的问题，有一定概率是集群中部分机器的问题，不要轻易推给网络，说是网络问题。要跟踪一个请求，从头到尾往下捋，一环一环排除。
0、没有add的文件, 手动删除就可以了。
touch install/wiki.sql # 只能手动删除, 不能使用git rm git rm install/wiki.sql fatal: pathspec 'install/wiki.sql' did not match any files # 手动删除 rm -f db.ini
《图解HTTP》用大量生动的图片，轻松、完整的讲解了一遍HTTP协议, 比那本大部头《HTTP》容易通读。2年之前看过，今天又翻看了下，有常看常新的感觉，特作一些笔记。
0、协议是计算机和网络设备之前通信的规则。规则的内容包含，如何探测到通信目标、由那一方先发起通信、怎么结束通信、使用那种语言通信等。
1、互联网是在TCP/IP协议族的基础上运作的，而HTTP属于它内部的一个子集。
2、TCP/IP通过分层管理协议，分4层即应用层、传输层、网络层、数据链路层。分层之后设计简单，每层只考虑自己层的任务，另外方便局部调整层的设计。
3、发送端数据包经过封包过程到达接送端，接收端经过拆包过程，把数据包送到接收端应用程序。
继续阅读
一、认识GC
Garbage Collection，垃圾回收，缩写GC, 是计算机科学中一种自动内存管理机制，通常也说是垃圾回收机制和垃圾回收器。是美国科学家John McCarthy与1959年发明用于Lisp内存管理。
简单说GC的作用就是把内存中程序不在使用的对象(称为垃圾)释放，归还给内存。这个过程实际上分为两步，
第一步：识别收集垃圾
标示出内存中哪些对象是垃圾。
常用算法
0、引用计数算法(Reference counting)
0.0 为每个存储对象附加一个计数器 0.1 当有其他数据与当前对象关联时计数器+1 0.2 关联解除时计数器-1 0.3 定期检查各存储对象的计数器，为0的将物理空间回收。 缺陷：无法回收循环引用的存储对象。
一、查看进程，ps aux
ps aux | grep 'niliu' #以上命令想必你一定不陌生，那么如果想快速知道每行的含义呢 [root@Mcqp15t170 chuanbo7]# ps aux | grep 'USER' USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 5637 0.0 0.0 112640 960 pts/0 S+ 19:28 0:00 grep --color=auto USER 每一列参数说明 +---------+--------------------------------------------------------------------------------------------------------------------+ | name | info | +---------+--------------------------------------------------------------------------------------------------------------------+ | USER | 进程所有者用户名 | | PID | 进程标识符 | | %CPU | 该进程使用CPU百分比 | | %MEM | 该进程使用物理内存百分比 | | VSZ | 该进程使用的虚拟内存(KB) | | RSS | 该进程占有的固定内存(KB) | | TTY | 终端名称 | | STAT | 进程状态(具体状态含义参考下文进程状态) | | START | 进程开始执行时间(当天显示小时:分钟；一天之前显示月:日, 一年之前的还没有遇到过) | | TIME | 进程实际占有CPU总时间(i:s) | | COMMAND | 启动任务命令行包括参数 | +---------+--------------------------------------------------------------------------------------------------------------------+ # 其实ps aux就行了，但是如果进程太大，不方便查看 ps aux | grep 'filterfeeds' root 16803 8.6 0.3 368496 43760 ? S 17:37 4:27 /usr/local/sinasrv2/bin/php /data1/www/htdocs/energy.tv.weibo.cn/public/cli.php request_uri=/cli_filterfeeds/index/proc_total/8/proc_num/6 root 16870 18.6 0.4 383204 59104 ? R 17:37 9:37 /usr/local/sinasrv2/bin/php /data1/www/htdocs/energy.tv.weibo.cn/public/cli.php request_uri=/cli_filterfeeds/index/proc_total/8/proc_num/7
进程状态:
D 不可中断睡眠 (通常是在IO操作) 收到信号不唤醒和不可运行, 进程必须等待直到有中断发生 R 正在运行或可运行（在运行队列排队中） S 可中断睡眠 (休眠中, 受阻, 在等待某个条件的形成或接受到信号) T 已停止的 进程收到SIGSTOP, SIGSTP, SIGTIN, SIGTOU信号后停止运行 W 正在换页(2.6.内核之前有效) X 死进程 (未开启) Z 僵尸进程 进程已终止, 但进程描述符存在, 直到父进程调用wait4()系统调用后释放BSD风格的 < 高优先级(not nice to other users) N 低优先级(nice to other users) L 页面锁定在内存（实时和定制的IO） s 一个信息头 l 多线程（使用 CLONE_THREAD，像NPTL的pthreads的那样） + 在前台进程组