Hexo插入图片解决方案

如果使用公共博客，其实没这么麻烦，图片、评论、推广都帮你做了，个人博客就要分别解决这些问题

方案

一般博客插入图片有以下几种方案

1. 公共图床
   1. 如网站上csdn、码云、百度链接上的图片，会因为定期扫描外链直接屏蔽
2. 私有图床
   1. 微博图床，配合浏览器图床插件上传、mac用ipic方便上传，但是半年后会清理丢失
   2. ipic提供私有存储：收费
   3. 自己的cdn服务开通：七牛云、又拍云、阿里云之类、收费
3. 博客本地保存引用
   1. 这种不会丢失就是上传内容多，需要本地工具配合更方便快捷

经历

个人一开始用公共图床，很快失效了图片，然后改用新浪图床结果半年后也失效了，现在使用最保险的第三种方式，真的是走过的血泪史，老文章的图片找时间恢复下

网上有说用，hexo-asset-image图片插件，原理是通过识别替换符替换生成html的路径，而且图片插入挺麻烦，要手工放入目录，然后再用快捷标识符引用

1. 提前配置：
   1. 修改根目录的_config.yml文件，这样创建时自动创建同名文件夹 post_asset_folder: true
   2. 安装插件npm install hexo-asset-image --save
2. 使用方式：
   1. 不过这样插入图片太麻烦，需要用{ % % }插入，一般的md的编辑器不识别
   2. 好像还有一种使用![你想输入的替代文字](博文标题/图片名.jpg)也会变化链接方式，不过没尝试成功
3. 如果已经安装想卸载：npm uninstall hexo-asset-image

推荐大家使用Typora编写markdown内容，所见即所得，使用Typora图片插入非常方便，直接复制粘贴即可，不过图片插入一个固定的全局目录中，所以为了让hexo与typora都能看到正确的图片内容，需要做一些配置

Action

一开始搜索了下与typora结合，网上没有一个能把图片插入说对的说全的

要么是root、要么是copy全局设置，其实只要2个同时设置就对的了

还一点是如果用每个文章的相对目录都生成一个文件夹的话需要路径变化，就需要hexo-asset-image一起配合使用了，这里不这么麻烦，直接把所有图片都集中在一个目录下，这样还能复用图片

第一步

在本地source中建立imgs文件夹，将引用到的图片全部放在此文件夹中

第二步

可以scaffolds->post.md增加

1
2

typora-copy-images-to: ../imgs
typora-root-url: ../../source

这样new的时候就有了，如果idea有设置live也可以改下

第三步

hexo n “xxxx”时就生成：

1
2

typora-copy-images-to: ../imgs
typora-root-url: ../../source

在拖动图片到typora中时因为typora-copy-images-to设置为imgs中，而root在source，所以会形成下面的相对路径

1

![image-20191007165004059](/imgs/image-20191007165004059.png)

这样在线下编写插入的图片就是如下格式，这样本地搜索路径就是../../source（typora-root-url）+/imgs/image-20191007165004059.png能在typora中正确显示

而在线上相对路径前面会加上域名：变为域名+/imgs/image-20191007165004059.png也可以正确显示

这样就完美了！

优化

可以用2个工具配合，先规整大小，然后再进行无损压缩！

简单的话mac自带的可以，不过只能减少大小，图片一般1280 即可先等比例缩小大小 sips -Z 1280 *.png

压缩会按照照片的最大边限定1280等比缩放

真正无损压缩，或者优化有部分损失压缩的工具比较好用的可以用ImageOptim

1. 官网下载https://imageoptim.com/howto.html
2. 使用非常方便，只要当前图片拖进去就开始压缩了，直接替换过去图片，可以先设置好启动有损，默认80%就可以，基本上6M图片能压缩到2M左右

最好是图片写博客的时候都是经过裁剪的，如截屏之类的

总体上多张图片115M，先进行像素标准化40M，然后压缩80%图片质量边25M左右，将近1/5的大小

路线

这次出行主要是父母一直想来北京玩玩，自己也想来北京玩过，中秋正好父母歇班有空就来玩了

父母需求很简单，就是去故宫、长城就行了，其他的地方去不去都行，所以主要是这2个地方安排吧

整体行程3天半左右，网上看了下马蜂窝、飞猪、携程的相关攻略，参考导游路线，还有各种景点的点评评分

期间9月12日-9月15日，包括实际路线情况，行程如下

1. D1：火车 → 天坛公园(2小时)→ 前门大街(1.5小时) → 北京全聚德烤鸭(前门店)(1小时)
2. D2：天安门广场&人民英雄纪念碑&人民大会堂4.6(1.5小时)4.7 → 城楼 → 故宫4.8(3小时) → 景山公园(1小时) → 北海公园(1.5小时)
3. D3：八达岭长城4.6(3小时以上,另一种是坐缆车到中间，登剩下的险峻的几段，然后走下坡) → 明十三陵4.5(3小时以上) → 奥林匹克公园站下 鸟巢 4.6 水立方 可以晚上夜景
4. D4：颐和园4.7(3小时以上) → 圆明园&明园展览馆4.7(3小时以上) → 北京大学4.6(1-3小时) → 火车
5. 备选：
   1. 中国国际博物馆 4.6
   2. 恭王府 4.5 雍和宫 4.6
   3. 慕田峪长城 4.8
   4. 国家大剧院 4.6，要买票进去

这次旅游完美的错过所有禁止游玩的时间，旅游之前陆续发出各种国庆封路的新闻

1. 北京7-8日天安门排练禁止旅游
2. 中间中秋节：12日-15日4天竟然没有任何干扰！！！真的是夹缝中选对了日子
3. 故宫博物院于9月21日至10月1日暂停对外开放，后面故宫14日也封了
4. 后续中秋14日晚封路等等

一直还挺担心的，不过全部都完美错过，真的是太庆幸了，免得重新安排行程

详细情况

D1

早上打的从家里出发去了火车站，乘车2小时左右到达北京，父母是头一回坐高铁显得格外好奇

北京站的出租车排队还是有提示的，前面多少人，这个在上海、杭州、济南都没见过，先进

中午先到如家酒店报到，定的2个房间，预定的时候多花了点钱每个房间每天都有早餐的，结果说只有我一个人房间有，说他们家系统与飞猪上的预定没匹配，协调一会，飞猪也投诉了把，最终是2个房间都给了早餐

酒店房间只能说一般般，而且当时图便宜只是睡个觉就定的无窗的，后来在那里虽然都是晚上回来住了3天感觉还是挺压抑的，以后还是建议订有窗的

下午打的去了天坛公园，刚一到门口就发现并没有想象中壮丽，一个是天坛南门本身没有太多修缮的痕迹，还有就是周边的老破小筒子楼胡同挺多的，这情况跟济南一样，被父母吐槽，哈哈

但是逐步进入公园往里就不太一样了

天坛公园本身是免费的，都是大片的树林老年人休闲场所，但是中间的天坛周边的景点是收门票的，之前网上定好的门票，二维码进入

进去是个大长道，从南到北，路过园丘、回音壁，最终来到天坛的核心建筑祈年殿，原来的认知上总以为天坛真的有一个叫做“天坛”的建筑，其实并不是，就是祈年殿

拍拍照，然后周边的几个房子看了看，前面的2个房子中有各种历史与文物介绍，皇帝、日本人、英法德、毛爷爷等这里的故事，然后就从西门出去

除了西收费口，来到大片树林长路中，这里的树都是一级二级保护植物，植树的位置都很讲究，前看血看都成线，小风吹着也很舒服，就在旁边椅子上呆了会，父母是真的爱上了这个地方

再往前走有个独特建筑连体的亭子，很漂亮

往南发现有个城池叫做斋宫，其实是皇帝拜天之前吃饭的地方，门票用身份证取免费的，下午4点半之后就关门了，那时候正好赶在最后进去了，护城河已经干涸，里面有钟、有各种屋子

从西门出了天坛本想带父母体验下地铁，结果入口不好找，最终走了一段路才到地铁，到前门的路程有点折腾，然后就来到前门大街的南口，一直往北走

刚到的时候人不多，然后随着夜幕降临，路边的灯光逐步开启，人逐步变多，本来计划去全聚德吃饭，不过看了下价格一顿饭人均200左右，父母觉得太贵没舍得去，想买支烤鸭一问也是79了还是算了，就去了前门大街小吃街里的一家面馆吃了下

D2

酒店的早餐说实话档次是不高，口味也一般，不过父母觉得还可以，凑合吧

D2基本按照路线走完

早上先打的到前门附近，地下道穿过马路到达天安门的西南侧，然后就是安检排队了，本来是没有安检的，由于最近十一大庆准备需要

安检后在大会堂、纪念碑、广场上拍拍照，正好多云，阴的时候拍照，否则很刺眼

再到西北角地下道穿过马路就到达天安门西侧了

跟着人群穿过天安门，毛爷爷这照片是多少寸的呀。。。天安门城楼说是可以上去，不过目前是上不去的

穿过之后继续往前走，经过端门，目标午门

午门是真的非常大，非常壮观，进去身份证检票后先穿过午门

然后可以从后面走到午门城楼上去，里面还有一些皇家物件展示厅。城墙上可以绕一圈，不过时间有限还是选择走正门路线

为了听故事，用的百度地图的解说介绍

先经过第一个门：太和门，特意拍了个全景

然后第一个大殿：太和殿

太和殿有龙椅，上朝的地方，仁德大隆，有4根金龙柱支撑

然后进去是乾清门，里面是皇帝居住的地方

买门票的时候还买了钟表馆与珍宝馆的，在乾清门没有着急去乾清宫，先是右边进入看馆的地方，不过要稍微排队下，钟表馆就是各种钟表，皇帝收藏的，很快就看完了

珍宝馆的东西是比较多的，个人觉得还是值得一看，里面有非常漂亮的文物，价值连城造型优美，可以开开眼界

中午就在珍宝馆里的一家小卖部解决

然后下午继续逛，先是从钟表馆旁边的道路看了下东六宫的情况，陆续看。。。

红墙是真的高，确实是深宫，看不到周边的情况，感觉还是挺封闭的

最终穿过各种门回到了乾清宫继续走中轴，乾清宫就是皇帝办公，批奏折的地方了，里面写着正大光明

门口的大水缸是用于救火用的，不过说是很多都被当时军队熔炼做武器了，现存的这几个是留下的

中间是交泰殿，盖章+皇上换衣处，交泰殿内部：无为二字

后面就是坤宁宫了，从交泰殿过去只能看到后门

后宫不得干政，所以坤宁宫大门是朝北，与皇帝与政务朝南的方向相反，再往北就是御花园了，本以为是很大一片，不过就走的路线来看长度并不长，比较有意思的是中间的2棵树长在了一起

其他宫就没有再去看了，像太后的慈宁宫在西边没有过去，然后从北大门神武门出去了，神武门与午门的大小完全不是一个量级

紧接着就是景山公园，门票只要2块钱，右边说是明皇帝明思宗吊死的地方，也没去看，直接爬山上去看全景，山并不高，一会就上去了，有几个亭子，不过只要上最高的万春亭那个就可以了

正面还有一个中心点标识，后面可以看到景山公园内的寿皇殿，还有中轴远处的鼓楼，这些都在中轴线上

南方向：故宫全景

从景山西边下来紧挨着就是北海公园了，路中还能看到一些胡同，北海公园从东口进，然后穿过桥中心岛逛了一圈从南桥出中心岛，然后绕了一小圈基本觉得跟济南大明湖差不多就出来了

中途在湖边做的地方休息了一阵，北海的南边就是常说的中海与南海了，也就是政府办公地点中南海

走的时候打车达不到，就做5路车，因为人多排起了队，父母吐槽说头一回做公交还要排队的…不过北京公交排队还有几路几路的标示在地面上

明天要去长城，定的一日游

酒店的早餐也是从外面做好运过来的，时间比较晚，时间是从7点开始的，旅行社的行程比较早，而且我们还是第一家接的，要求我们是凌晨4点就要准备好，所以只能自备早餐了，去超市买东西

为了准备早起，早早的就睡了，而且这一天也确实走了不少路，好好休息一把

D3

一大早北京凌晨4点就坐面包车拉到集合点了，在朋友圈吐槽见过北京凌晨4点后出发，坐上大巴，差不多1个多小时就到了八达岭，5点多出发大约6点40到达，家里父母一起不想爬的太累，跟着导游一起买的滑车上下

滑车体验真的不错，就是一开始上去有点陡峭，但是下来的时候是真的好玩，推荐滑车上下

滑车下来后就到了中途的好汉坡，拍照主要是需要有遮光的镜头才能拍好，最终还是花钱洗了几张照片，自己拍的脸都是黑的

从第四坡开始爬一直到第八坡，这一段也挺陡峭，但是并没有想象中那么难，一会就上去了，拍拍照原路返回滑车下去，路上从第六坡可以走旁边的下山路下去而不用再走长城不好走的路了

大巴集合去吃饭，这个车转的是真的晕，有人都吐了。。。

吃饭中还给了北京烤鸭尝尝，完事后去往十三陵方向

先是看到了碧玺，摸头，摸尾巴不得病

这个地方是个风水宝地，前有水，后靠山，两边也是封死的，不过后来开了路，一共13个陵，长陵是朱棣的，不过只开了上面参观，开的地下的陵只有一个叫做定陵，听说是最谈钱的一个皇帝

每个陵都有一定距离，长陵不过看处不多所以就不过去了，主要看定陵，十三陵分布图如下

这里面有很多故事了，中间过程没有拍照，记得应该是导游说拍了不好，没拍~

进十三陵一定是走旁边的路，因为中间是升天的路，不吉利。还有就是要

其实地面被烧了好几回，其中清军来的时候就先烧了这里，改朝换代要先断龙脉

下去后基本上有皇帝的石凳，皇后的，还有爱妃的，共3个，还有就是3个人的棺材木，还有旁边的26个大宝箱，不过听说宝箱里的东西大部分都没有了，好像是WG时期，红卫兵给烧了，因为皇帝是最大的地主

然后下午3点多返程，后面有额外的奥林匹克公园导游行程，正好也报名去了

先是坐着浏览车饶了一圈，从水立方停下

水立方目前已经改名冰立方了

鸟巢，还有鸟巢前的价值5亿的玉石头

整个奥林匹克公园的布局非常讲究，中轴，各种龙脉，地龙、水龙，还有各种建筑的讲究，钉子塔，盘古七星大厦

比较玄乎的就是水立方南边的娘娘庙了，听说水立方本来要建在这里，但是施工的时候发生了怪事，因为动了风水导致灾难，最终水立方往北迁移了

最终这天结束要回去了，不过路上因为2环内封路了，所以走了3站公交站才坐上公交

D4

上午吃完早饭，剩余的几个公园也没有预定讲解的导游，只是自己去逛逛其实也挺没趣的，以后再说，父母也累了，提早改签回去休息了

总结

北京游玩确实是需要历史了解与旅游解说才有意思，这方面主要是在十三陵、故宫与圆明园这几个景点上

所以部分选择导游（尤其偏远地区）、或者购买电子导游服务是必要的，否则就是走马观花，手机导游的坑是有的，人多的地方会没网，所以还是人讲的好

北京的很多风水是比较讲究的，虽然是科学发展观，但是风水依然在国家层面是看重的，有些事情没有博客上写，关于龙脉、数字、事件有很多关联，很多现象太巧合，还是挺难解释的

我这个行程安排的还是比较紧的，如果D4玩完估计回家是比较累的，其他人制定可以一天砍掉1-2个项目，会更轻松一些

其他经验

1. 提前规划路线很重要，前2天的门票可以提前买好，后面的看情况
2. 预定酒店还是定有窗的比较好，加早餐省事
3. 按照自己身体的情况，行程可以安排满，第二天基本能恢复体力，但是有必要最后预留1天时间在家休息调整
4. 相机拍好了是真的不错，不过手机是真的方便，相机还是太沉了。手机的缺点是要人像识别准，否则会把人脸拍成背景还调整饱和度导致失真，选择轻量级相机或者手机
5. 轻装上阵，尽量拿更少的东西，水带着2瓶即可否则太累。可以带点小零食休息的时候补充能量

总之整个北京之行不管自己还是父母都还挺满意的，有机会再去补完景点~

Netty与NIO

感觉很多文章都讲不到重点，很多都是API层面怎么用，很多同学搞IO这块看的也是一头雾水

今天来了兴致写一篇吧，一气呵成，前篇没有去查任何资料，全靠记忆与理解回顾，后篇是很早之前学习过程的笔记贴上，如有问题欢迎指正~

Netty用于高并发服务开发，基于NIO，要想明白Netty，要先知道NIO的情况，然后多了解下操作系统就OK了，不想说netty你的性能优化真的是各种数组替换hash结构的骚操作太多~

PS：这篇涉及IO模型、堆外内存、Netty分析、操作系统IO原理、内存分配、并发实践等内容，后续有空配图

NIO

在Java1.4的时候就提供了nio的支持，non-blocking I/O，好多也叫new I/O，主要是非阻塞的实现，本质还是同步的通信模型

这里就会有人问了，非阻塞不应该是异步么？这就是没分清楚的表现，这种问题还经常出现在面试题中（其实是我经常问。。。）

首先概念要先搞清楚

1. 阻塞与非阻塞指的是调用方的情况，同步与异步指的是通信的模型
2. 本质上你调用的IO通信接口都是操作系统提供的，操作系统的接口你调用之后就阻塞住了还是立即返回这叫阻塞非阻塞
3. 而你调用系统之后，系统又与TCP与网卡交互，有数据之后操作系统会把数据传输到应用程序中的过程是通信过程，如果操作系统只提供了查询有没有数据的接口，你只能去拉数据确认有没有那这就是同步，如果系统提供回调通知的方式，来了数据会主动回调你，避免了你不停的去轮询这个就是异步通信，是个推的过程
4. 其实IO上的阻塞总是有的，只是说应用处理上是不是阻塞的，如果可以把数据处理与接收请求2个事情分开这个事情就解了

先看看Java吧

1. 1.4之前都是用BIO模式，还记得那些讨厌的装饰器模式的InputStream与OutputStream之间的嵌套使用么，那个就是，在Socket编程中基本都是服务端Socket调用accept方法来返回Socket对象才能操作客户端的请求，如果没有请求，那就要阻塞。这有2个问题，1是主线程只能卡主不能干别的，2是主线程accept到socket进来了还要去执行任务，这样下个socket请求就只能卡在TCP缓冲区里了要等这个处理完才能处理，服务端瞬间变为同步模式排队处理请求，所以BIO时代处理都是用线程池玩儿，这样虽然服务端监听accept还在卡主，但是多少是可以并发处理
2. 1.4之后的nio，提供了一个selector方法，open一下，然后监听accept事件，虽然没有事件也是阻塞的，但是一旦有了事件会返回一个List<SelectKey>，这是一组Socket请求，然后你就可以while循环一个个去处理，当然你不是直接去处理，这就跟刚才没区别了，而是NIO中accept与用户读写事件完全分离了，accept之后如果想去读写数据可以再单独去订阅读写事件，那刚才接收到accept的主线程就直接用另一个selector去订阅read事件，这样刚才那个selector就可以独立去处理请求了。重要的是读写的时候也是一批List<SelectKey>去拉取处理，这样相当于术业有专攻，有专门批量处理请求的，也有专门批量处理读写的，谁也可以不等着谁的流程。底层其实还是同步去确认系统数据的，只是API上通过监听分开，达到了非阻塞的目的，同时采用的是多路复用的IO模型，这个后续会讲
3. 1.7之后提供了aio，这个就是刚才说的非阻塞异步模型了，不过使用的人真不多，netty曾经用过不过效率还没nio好，所以也弃用了，以我的感知认为其实在推拉模型中跨单元调用拉可能是大部分设计比较好的方式（不过也有特例，比如现在的Reactive模式，Disrupter模型）

说下NIO底层

1. 其实nio底层采用的操作系统的epoll方法，这个epoll相当于在每个socket的队列中都插入epoll指针，自己也维护一个用户测注册epoll的回调，当网卡收到数据会中断操作系统来接收数据（中断是操作系统的机制，就是IO总是有限的，CPU忙到中间IO有读写CPU就要中断程序优先响应IO处理），操作系统会读取数据写入socket文件中（linux中设备、网络都相当于是文件，fd），这时候epoll就发现来数据了，它给每个socket都增加了队列监听，来了数据就去从系统的socket数据登记列表中查哪些socket有数据（操作系统维护了一个数据通知的表避免epoll把所有socket遍历一遍，低效），然后去拉取数据然后再通知到自己的队列中监听者回调数据通知，返回一批的selectKey事件告知来数据可以来取了
2. 其实在epoll之前，还有select，与poll，select方法比较笨，监听与读写是一体的，而且要遍历socket才知道有哪些socket有数据，poll稍微优化了下，2002年诞生的epoll目前基本都在用，比如redis、netty、kafka，底层都是epoll。这里需要注意的是Java的API总是在说selector，但是底层是epoll不是select，此select非彼select，不要混淆。
3. epoll也有2种触发模式，水平触发与边缘出发，边缘就是快到了就通知准备，JDK提供的NIO是采用水平出发方式，在netty中就提供了底层的边缘出发，效果更好，在netty中就是EventLoop是Epoll开头的那些类

理解IO模型

再来看看操作系统的IO模型吧

1. nio刚才讲了其实是非阻塞同步，那与操作系统打交道，操作系统到底提供了几种，答案是5种，4种同步，1种异步
2. 同步阻塞、同步非阻塞、多路复用、？、信号异步
3. 其中多路复用是同步非阻塞的升级，同时监听多个Socket，也就是刚才说的epoll的模式，而信号异步就是aio，同步阻塞就是那个bio了，其他2种都是鸡肋

说白了，其实JDK中关于IO它自己还真没怎么去搞什么优化，大部分还就是包装操作系统的方法而已，要想学好IO，包括文件IO、网络IO，那还是学好操作系统才能完全搞明白

Channel与ByteBuf

接下来还要给大家介绍2个概念

1个是channel、1是个bytebuf对象，有时候是不是困惑这个堆外内存的情况？因为它不属于JVM堆管理的范畴，是直接操作系统中的内存，那为啥高性能的框架组件总喜欢直接操作操作系统的内存呢？这就涉及到进程与系统之间IO交互的问题了，一步步说明吧

1. 操作系统与进程的内存是分开的2部分，一部分是内核态，一部分是用户态，所谓用户态就是每次分配一个进程的时候给你开辟一块进程的内存空间让你自己去玩，比如Java进程就开辟一块JVM用去分了栈私有空间与堆私有空间，这个就是Java的内存模型JMM，这都是一个进程自个儿定义的，怎么玩都没关系，而IO就不一样了，如果进程想去碰一个文件，或者一个网络上的传输的数据，那就要通过磁盘，然后到内存，内存还是先在内核内存，然后要copy到用户进程内存中才能使用，这个过程好处就是因为每个进程内存模型自己玩的，一旦数据跑到用户态内存中，比如Java中就变为堆上的对象了，可以用GC回收处理了，不用管太多，用户操作也简单，但是效率低，至少要copy一次，所以就诞生了直接去内核态里去读取内存与分配内存的骚操作，比如文件写入的缓存直接写到内存分配的内存中，或者读取直接读取内核内存中的数据，这样就减少了copy的过程，这就是大家一直在讲的零拷贝优化了。但是有个缺点，就是内核中的内存使用就要按操作系统的内存玩法去玩（一会提到指针问题），而且稍有不慎可能就堆外内存溢出了，所以一般提供的API都有一些限制，在Java中，这个东西就放在ByteBuffer对象中，可以通过ByteBuffer#allocateDirect分配，JVM还会限制堆外内存分配总大小，Unsafe#allocateMemory也是直接可以分配的，不过这东西更底层，Unsafe只能用特殊方法调用（我其他博客中有讲）
2. 不过这个ByteBuffer操作是真的挺难用的，因为总要控制几个指针，一个是read，一个是write，还有一个总共的大小，还要各种重置清空的方法，read<write<总大小，这样来控制你写入多少读取多少，如果读过头了其实是错误的数据，JDK中也不允许这么玩，而且JDK还会保持一个引用好进行一定程度的回收，总之这个ByteBuffer就是可以用于操作系统内存了，其实也可以分配的堆中，相当于2个实现。这个回收相对而言netty做的就比较贴心，有个兜底的方式给你回收掉，后面会提
3. 读取文件还有更多骚操作，比如直接把文件映射为内存映射，就是虚拟内存，在程序中读取虚拟内存加快速度
4. Channel的理解：操作系统层面有channel，是为了避免CPU直接与IO打交道，直接开辟的内存读取的方式形成一个Channel通道，Java中的FileChannel，还有Nio中的网络Channel都是这个东西

所以要想真的让NIO更快，那必须用channel+对外内存ByteBuffer来处理，这个netty都是有的

PS：关于文件句柄限制、内存区域与优化的东西还有一些问题，netty章节会讲

Netty

大约3年前我还一直简单的认为netty只是对JavaNIO太难用的封装+个reactor模型而已，后来看了下源码与资料，发现果真如此（说好的转折呢？），不过netty对性能细节的把握真的是独到的，而且API还是比较灵活易用的

核心组件

1. NioEventLoop/xxxEventLoop：事件循环，包含一个group里的公用线程池、selector引用
2. Channel：是对socket请求的抽象概念，netty中的channel又对javanio的channel包装了一层概念
3. Pipeline：可以理解为责任链中的chain的作用，里面可以添加ChannelHandler
4. ChannelHandler：就是责任链中的比如filter的实现，来处理read数据与write数据
5. ByteBuf：对JDK的ByteBuffer的封装，带有自动回收与复用的性能神器

程序流程

总结流程

Netty的整体流程可以分为服务端与请求处理端2部分

其中在执行服务端启动的时候，bind方法时就把服务端的EventLoopGroup，对应的Channel与pipeline触发完毕，调用服务端eventloop.execute方法启动执行监听

在bind中的init的时候也会去调用请求处理端Work的eventloop的execute方法启动监听

服务端eventloop在监听到selector有请求的时候会请求到请求处理端Work的eventloop中经过pipeline处理

监听请求：EventLoopGroup持有多个NioEventLoop，会无限循环找任务并监听端口的selector的请求

1. 通过路由器chooser#next方法依次轮训选择，多个EventLoop共用一个ThreadPerTaskExecutor线程池，每个EventLoop并持有一个优化后的selector对象
2. 在channel执行eventloop.execute的时候，内部会持有thread的引用，在非当前thread执行时封装task丢入到queue中，这样EventLoopGroup在执行的时候会先检查queue来执行，然后才去selector任务

发现请求，转换工作：当检测到有请求到来时会受到SelectKey，然后调用processSelectKey方法，内部用unsafe读取，最大读取16个channel，并且逐个包装为Netty的NioSocketChannel对象，workEventLoopGroup会去注册这个channel，然后读取byte数组遍历使用pipeline的fireChannelRead传递byte数据

业务处理：work的pipeline通过head、ServerBootstrapAcceptor、tail的调用完成请求处理，其中ServerBootstrapAcceptor包含了用户的ChannelHandler经过，每个ChannelHandler都持有ChannelHandlerContext来操作传播

1. 读请求正向，写请求逆向，异常请求正向

Boss流程

bind接口

服务端启动主要流程就在bind接口中

1. initAndRegister初始化：
   1. newChannel：通过用户传入的Channel，如NioServerSocketChannel反射实例
      1. 构造方法：初始化pipeline、config、unsafe，channel对象设置非阻塞configureBlocking(false)
   2. init：对channel设置options、attr、pipeline最后添加一个channelInitializer
      1. pipeline添加ServerHandler
      2. channel的eventloop.execute一个函数，pipeline最后添加ServerBootstrapAcceptor对象，传入childOptions，还要用户定义的childHandler（channelInitializer对象）
   3. register：调用group（childGroup，就是最初传入的NioEventLoop）的register这个channel对象
      1. 把channel中的eventloop=这个NioEventLoop
      2. NioChannel实现中就是启动Java的selector对象注册0兴趣，不关心任何事件，只是做个selector与channel的绑定，传递了this用于java selector回调channel方法用
      3. 然后触发2个回调，handlerRegisted、handlerAdded2个方法（要ServerHandler实现ChannelInboundHandlerAdapter），这里由于还没actived，所以不会触发激活
2. doBind方法
   1. doBind变为actived
      1. NioServerSocketChannel实现
         1. eventloop.execute添加一个bind绑定端口的任务
   2. pipeline的fireChannelActive
      1. 通知激活后，还会触发read绑定selector的操作，从0变为read

Work流程

work的主要流程开始就是在服务端接收到请求时对work分配工作时操作的，关注pipeline

Pipeline

NioEventLoop中有processSelectKey方法

1. 用unsafe读取，while循环只要继续读，内部通过JavaNio获取JavaChannel个数，读取while条件中最大读取16条，如果中途读不到数据也会break跳出，读取的Channel会包装为Netty的NioSocketChannel，内部会做一些事情
   1. 设置非阻塞，创建unsafe、id、pipeline
   2. parent就是通过那个通过反射创建的channel
   3. setTcpNoDelay(true)：如果是false tcp会将小数据包转换为大数据包才发送，不过netty想尽可能快的让收到数据，所以禁止了，默认非android的默认都是禁止的
2. 读取数据后，遍历readByte，然后调用pipeline的fireChannelRead方法传递byte数据
3. pipeline调用顺序：head->ServerBootstrapAcceptor->tail，channel创建是诞生的pipeline
   1. head与tail是创建pipeline的时候就有了，tail是outbound处理，如果异常没处理，信息没处理这个就是兜底收尾的事情，head是个inbound，写都是用unsafe操作
   2. ChannelHandlerContext中具备属性存储，读事件传播，写事件传播的3个接口实现
   3. 在fireChannelRead方法中，用户编写时使用chilidHandler的ChannelInitializer的ch.pipeline去添加ChannelHandler实现，添加完后会把ChannelInitializer自己删除，用户自己设置的options与attrs都会设置到channel的config对象中（也是用户侧设置的），然后workgroup去注册这个Channel，注册方法内部会调用next函数找到一个NioEventLoop去执行，最终注册调用的是底层javanio的selector的注册0感兴趣事件，然后后面就是开始调用pipeline的head节点传播了，head会去注册读事件（这个逻辑与服务端启动的逻辑相似，dobind方法中在监听端口后也会触发一次读请求）
      1. 会先判断是否重复添加，添加是基于双向链表尾部操作，删除要先找到节点然后删除，添加删除都有回调
      2. ChannelHandler分为Outbound与Inbound，还有对应的adapter实现
      3. inbound是next正向传播到tail（tail也是in），如果buffer会自动释放，考虑周全，而outbound是逆向传播到head（head是out），而异常传播是inboundoutbound都是正向传播
      4. context.channel.write是从头传播（更常用），而直接context.write是从当前节点传播

公共部分

Channel

1. AbstractChannel：持有unsafe、Pipeline、channel
   1. AbstractNioChannel：持有selectKey、selector
      1. AbstractNioByteChannel持有NioByteUnsafe，客户端的，监听read
         1. NioSocketChannel持有NioSocketChannelConfig
      2. AbstractNioMessageChannel持有NioMessageUnsafe，服务端的，监听accept
         1. NioServerSocketChannel持有NioServerSocketChannelConfig

客户端 服务端 都继承 说明都是基于selector

1. 不过监听事件不一样，服务端监听accept、客户端监听read
2. 还一个对应Unsafe不一样，主要是读写抽象不一样，客户端读数据byte，服务端读连接

EventLoopGroup

EventLoopGroup，默认不设置线程个数是0，会用2倍CPU线程数

1. new 一个线程执行器ThreadPerTaskExecutor，实现Executor接口实现的线程池，factory里线程池开头小写命名线程名，创建的Thread是FastThreadLocalThread，这个Thread继承Thread，重写ThreadLocal为数组的实现，性能优化点之一
2. 按线程个数初始化线程child
   1. 在NioEventLoopGroup中的newChild会new NioEventLoop，触发构造函数逻辑
      1. provider，openSelector产生selector引用持有，一个selector对应一个NioEventLoop
         1. 通过Class.forName传入System类加载器+sun.nio.ch.
         2. SelectorImpl获取Class对象，然后针对selector对象中的Set<SelectKey>默认的HashSet替换为netty自己的实现，用数组替代时间复杂度从On降到O1
      2. TaskQueue：newTaskQueue：mpscQueue，如果不是当前线程的任务会塞在队列里，代表外部线程用的任务队列
3. chooser选择器构建，传入全部NioEventLoop对象
   1. chooser会调用NioEventLoopGroup#next：NioEventLoop[] ，每一个新连接是从0到N依次去绑定任务，最终从多个里面返回一个NioEventLoop
   2. 特定优化：如果是2的幂次方性能优化的策略：每次next时自增id+1，然后要选择EventExecutor[]数组（NioEventLoop的父类）中的一个要取模，2的倍数直接用&（长度-1）操作，可以二进制过滤出余数，如果是非2个倍数，直接%长度取模，&比%高效
4. execute方法
   1. EventLoopGroup中的executer线程池会调用execute，内部run方法，如果是第一次这个channel会保存这个thread的引用，如果是第二次则会判断执行是否是当前线程，如果不是当前线程就封装为一个task放到queue串行执行
      1. 方法执行一个SingleThreadEventExecutor.run
         1. 这个run里会无限循环，然后去调用selector对象找SelectKeys数据IO数据，每次会统计select的时间
         2. 先检查任务按照截止时间排队是否到期，没有检查是否有队列任务，没有就执行真正的selector操作processSelectKey
            1. 阻塞1s获取，如果selectKeys不为空、被唤醒、有任务了，就终止select操作
            2. java的niobug就是不阻塞 然后就不停的轮训导致cpu100%。这里判断是否执行时间大于阻塞时间，如果小于阻塞时间说明 select 没有阻塞直接就返回了，超过512次就重新建立一个selector把所有事件转移到新的selector 这样可能就好了
         3. 处理异步队列中的任务
            1. 除了普通任务，还有定时任务，scheduled，有个PriorityQueue优先级队列，按照截止时间来排序
            2. 因为queue不是线程安全的，如果是在事件循环中就直接queue.add，如果不是就execute一个run把queue.add添加进去来保证queue的线程安全（netty如何保证异步串行无锁化？）
            3. 触发会把到期的定时任务放到taskQueue里面
            4. 无限循环，任务执行，nanoTime也是耗时操作，所以每执行64次，才去计算时间如果没有结束

内存分配

read只能读取写入的数据，capacity是空间最大值

Unsafe可以直接拿到对象内存地址，可以直接内存读写，非Unsafe是直接拿一个数组的一个索引值，Unsafe 这个是根据jdk来自动判断的，看是否能强行获取JDK内部的Unsafe来来操作，使用者不用关心。Unsafe的读写数据更快

Heap不需要手工释放在堆，Direct需要手工释放

另外2个维度是用实现来区分 Pool与Unpool，区别就是PooledByteBufAllcator，内部有PoolThreadCache，可以在Area上分配

1. 提供了内存分配管理器ByteBufAllcator，有堆、直接内存分配的方法，主要区分 堆内与对外的接口
2. tiny、small、normal3个不同大小的bytebuf 缓存多少个，每个thread到时候分配是直接拿走用，不用用的时候才去分配，这样更快
3. 每个对象中持有一个handler用于回收，如果缓存没分配成功会直接分配

内存规格：比较复杂，最终得到效果：分配内存规格然后缓存，防止分配耗费性能

1. tiny（0-512b）、small（512b-8k：512、1k、2k、4k）、normal（8k-16M：8k、16k、32k）、huge（超过16M） 就是这4个区间
2. 操作系统规定16M要去申请一个Chunk，所有的内存申请向系统的单位是Chunk，分配1M也要先申请一个Chunk，然后再在Chunk里取一个
3. 8K是一个Page ，16M有点大，拆分就用Page来取，2^11次方2048个Page，所以一个Chunk包含2048个page，一个page是8k，16k就是2个page
4. subpage就是0-8k之间 还很大，netty定义的small、tiny、normal，而huge是直接走的非缓存的分配，每种类型的每个一个小规格都有一个queue存储
5. Chunk链表，netty会分析使用情况 组成chunklist用于分配，分析使用率，还是用到了ThreadLocal隔离

解码

netty是基于TCP层之上的组件，这个与socket一样，客户端监听服务端IP+端口，而服务端需要绑定端口

所以接收到的数据是一个byte[]通过协议转换为报文内容，然后再处理，最终再转换为报文，转换为byte[]的过程，这个过程其实就像生产处理流水线一样，所以是放在Pipeline中的一个个ChannelHandler来处理的

ChannelHandler默认提供了一堆编解码的基础能力实现，比如

1. 基于byte长度分割字符
2. 基于\r\n或者\n的行分割字符
3. 基于分隔符号，比如逗号、分号这种分隔符处理器
4. 还有基于数据域的方式，先解析接下来数据长度，然后读取一段，再遇到一个长度数字再解析一段，里面有不少可以调节的参数

整体上这些处理器都具备一定容错能力，主要是比如一直读取不到（可以设置上限）分隔符就会抛弃到下一个分隔符的一段数据，实现层面是通过一个byte累加器来实现，在他们父类中

虽然整个业务逻辑都是ChannelHandler，但是也要区分下职责，比如有只负责读的，有只负责写的，也有读写都行的，那就是分别是inbound与outbound2个接口，inboud对应read的相关方法，outbound对应write的一些方法

write操作

1. 如果直接是堆外就返回，否则就把内容 写到 堆外内存中的转换，写byte操作几个指针，一部分flush了，还有没有flush的，如果积累的没flush的数据超过64k就自旋锁+CAS阻塞不可写状态。每次flush就size-1，如果小于32k就设置为可写的状态，head会保证数据都塞到堆外内存去，最终数据转为JDK原生对象写入

性能工具

这2个工具类 也可以单独去用

1. FastThreadLocal是自己维护了一个map，继承Thread，内部的ThreadLocalMap底层用数组实现提高效率，自动扩容
2. 对象池Recycler，基于fastThreadlocal，bytebuf就是用这种方式回收，ThreadLocal中获取stack，然后pop，是个handler，如果handler没有会创建，里面包含value还有stack的引用，可以同线程 回收，也可以另一个线程会回收对象
3. 另一个零copy的点：CompositeByteBuf，用addComponent取代ByteBuf#writeByte，可以把2个内存直接当连续的读取，这样减少的内存copy的代价，内部实现也是先找到组件，然后再找空间

实践

百万并发调优

1. 模拟百万：用8000-8100端口，一个端口顶多6w请求，1024-65535 ，扣除常用端口，实际只有6w左右连接，单机也就6w，但是多客户端 连接 太费机器了，所以用多接口方案

2. 一个文件一个句柄，突破

   1. ulimit -n 查看句柄

      /etc/security/limits.conf

      1 2	* hard nofile 1000000 * soft nofile 1000000

      *代表当前用户，hard是真正限制，soft是警告限制，nofile表示能打开的最大连接数
      任何用户最终能打开100w文件

      需要重启

3. 一个系统的限制需要突破

   1. cat /proc/sys/fs/file-max

      /etc/sysctl.conf 添加一行

      1	fs.file-max=1000000

      sysctl -p /etc/sysctl.conf 生效

4. cpu可能会标满

线程数可以调优

1. 任务线程里自己搞个线程池把耗时代码隔离
2. 在pipeline.addLast中可以添加businessGroup新建一个，整个Handler逻辑隔离
3. 线程数要不停的尝试才能达到最优

技巧

1. telnet 127.0.0.1 8888 连接netty服务端，然后输入内容测试服务端

最近看了龙珠的电影，发现跟小时候看的完全不一样了，各种新人物，各种赛亚人等级，于是查了下资料重新认识了下龙珠的世界观

龙珠设定

龙神萨拉玛曾是和全王都是地位非常高的神，全王是宇宙万物破坏之神，而龙神萨拉玛则是宇宙万物创造之神

龙神萨拉玛创造了超级龙珠，大神官当时应该是全王的天使监督

萨拉玛要夺取全王的破坏宇宙能力，大战，最终萨拉玛被封印，而全王丧失心智

大神官全宇宙的最高统治者全王的管家，对全王忠心耿耿，已知儿女有维斯，芭朵斯，科伦，都是天使

原本一共有18个宇宙，其中的6个宇宙因惹怒全王已被全王消除，现在12个宇宙

每个宇宙都有对应的破坏神，监督破坏神的天使，与创造神也就是界王神，天使是破坏神的师傅与监督

天使维斯能力：创造物品、时间前进与倒退、灵魂复活

第7宇宙就是地球与主角们所在宇宙，破坏神是，天使是维斯，界王神分为5个人，东西南北界王与大界王负责管理、界王下面还有一个星球管理者就是神（克比）

孙悟空形态：赛亚人、猩猩、超级赛亚人1234、红色、蓝色（神）、玫瑰红（神）、白色（神）、自在空

超强的赛亚人：布罗利、孙悟空、贝吉塔、孙悟饭、特兰克斯

背景

平常时间不多，看书断断续续，这本书基本从18年年末看起，看到现在才看完，作者花了半年写书我花了半年才看完，惭愧~
整本书450页，前面偏作者总结的理论知识，大章后面会带有小案例，后面讲京东的商品页偏实践，也算是理论+实践了
不过读前半段总感觉例子比较牵强，直到后面看到商品页时发展原来都是这个大例子中拆出来的小例子，所以前面的例子很别扭，后面很重复，也算作本书的缺点之一
全篇知识比较硬，作者不开玩笑不举现实例子全篇抽象与代码例子，内容相对死板一点，不过也有不少干货小点

说说作者

其实我在15年工作的时候就经常看开涛的博客，原因是我搜索时百度给我的头几个帖子都是他的博客内容，看来那时候他就很知名了
记得最初看他的博客是关于「跟我学Shiro」的系列文章，因为那时候正好在负责公司多业务线的基础平台整合需要用到Shiro框架，看他博客带入门了
感觉他博客学习技术由浅入深还不错，所以后面还看过他的「跟我学Spring」「跟我学SpringMVC」系列回顾了下基础知识颇有意思
后面再关注时发现他在发一些nginx与lua技术的文章就不太感兴趣了，原来他15年去了京东，就开始搞这块东西了
总体来说，我当时只是觉得他写基础入门博客还是挺好的，直到他出书发现当了京东资深架构师才发现这家伙成长真够快的，原来他还能写一些架构的知识，不过就是写的一般=。=

内容

全篇围绕互联网架构技术中的特点，把所有关键字基本过了一遍
包括了单机能力的提升与分布式领域能力提升多个维度，我把其点重新分分类，这样看起来会更加清晰
同时作者对高可用高并发的分离也有些混乱与错乱，我也稍微调整了下顺序更加合理

流程与原则

1. 经验规律：墨菲定律、康威定律、最小产品、二八原则
2. 设计原则

主题达成

1. 高并发：TPS，多短时间内请求量、增加吞吐，降低延迟
   1. 吞吐：扩容、负载均衡、反向代理、池化
   2. 查：缓存、并发、异构
   3. 写：队列、批量
2. 高可用：3个9，4个9，多长时间内成功率
   1. 隔离
   2. 部分可用兜底：降级、限流
   3. 循环执行：超时、重试
   4. 灾备：冗余、回滚、压测、预案
   5. 人肉高可用：告警

高并发方法论

1. 扩容、负责均衡、反向代理
2. 池化技术
3. 缓存技术
4. 异步并发
5. 队列

高可用方法论

1. 隔离
2. 限流
3. 降级
4. 超时与重试

具体技术

1. Servlet3
2. Nginx
3. OpenResty：Nginx+lua

总结与思考

其实高并发在业务实践中有更多的可玩性与灵活性，往往是提供可靠的中间件与运维组件，而业务方依赖这些组件定制策略，灵活度高，这个往往是业务线的专家做的事情
而高可用往往会做到环境与中间件中，往往高可用是需要上下文联动才能达到高可用，所以只有环境做的不好周边设施不完善时才有业务自己去定制开发，这个往往是平台架构师做的事情
高并发是多短时间内请求量，高可用是多长时间内成功率，简单总结一下就是要让系统又猛又持久

整体书的内容对于自己的架构还是有能引起思考的，书中提到的东西基本也是技术老生常谈并不新鲜但是很实用，由于加了实践的经验还是值得一读，最终采用nginx做网关的设计虽然我不是太赞同作者架构观点，但就像开篇点评说的一样，虽然内容不一定是对的但是经过推演假设实践后不断优化就越接近本质，设计也就更合理，做一个有思想的架构师很重要，所以我还是比较欣赏作者的，很有思想自成体系，内容则可去其糟粕取其精华

今年没加班也没有晚回去，只是提早回来几天，算是比较正常的回家过年了
不过今年才逐步发现很多过年才去做的事情逐步都不做了，年味变得越来越淡
不过细细一想其实最重要的东西还在，那就是与家人亲属朋友团聚，所以形式上的东西也就无所谓了

年味的变迁

每年过年都会少去一些过去年味，这些年味体现在从地点，周围人，娱乐方式，衣服，饮食上面

1. 老人：因为爷爷奶奶去世，再也没有大年三十那种大团圆在爷爷家吃饭的场景了，一家族人一起看春晚的热闹场景，小辈们一起玩游戏抢电脑打游戏，逐步变为一家三口在自己家过年，现在是一家四口了，家族改为初一聚餐
2. 衣服：也没有以前那样每年才去买一套衣服，所以也不会去与父母逛商场买衣服鞋了，现在衣服随便买
3. 鞭炮：市区取消了炮竹，禁止放烟花爆竹，去年好像还有几个小时可以放，今年则一点声响也听不到了，即使到了凌晨，倒是不用担心吵得睡不着觉了，但是总感觉过了一个假的除夕
4. 节目：以前看春晚，后来逐步放弃春晚，改为看看网上的视频，如AB站的拜年祭之类的，不过这类节目只能一个人看不能陪父母，所以后来还是去看春晚了，陪着爸妈比较重要，顺便一提今年的AB站没有好节目很失望改成直播有点不自由
5. 饮食：老妈高血脂高血压迹象，老爸高血糖糖尿病，不能吃甜、咸、油、辣、饱，所以也不能吃什么了，所以今年取消了油炸物品（炸鱼、炸藕合、炸肉），取消了酱牛肉，火锅吃了一次没啥好吃的以后也取消，以前觉得过年吃的最好现在感觉也平淡了

保留下来也不多

1. 赶集买菜
2. 家里打扫卫生
3. 老妈一年只有的一次长假、与发小们聚聚聊聊、年初一的家族聚餐、年初二的老娘家、亲戚们的串门

衣食住行上其实现在过年吃的与不过年差异也不是那么大了
感叹过年家里习惯逐步取消了，再也不是儿时的感受，时间的改变
只是一些家的味道不会变，比如妈妈做的卤子面，水饺，可乐鸡翅，爸爸炒的辣子鸡，吃到这些后才感觉回到家里的那种幸福，还有老妈的笑容，老爸慈祥的样子

现在想来过年主要还是团聚与交流最为重要，其实全家人一起旅游过年也是一个不错的选择

win2go安装

一个是黑屏
一个是安装更新坑爹，只要强行重启就好

安装windows

win to go 360总是提示不能安装到移动设备，无语，可以禁用一键安装

安装时可以先禁用磁盘，最终再分配盘符

就在18年12月底，亲戚来上海做了肠道相关的微创手术，于是除了对方的父母，我也过来帮忙，其中家里也多住宿人来减少住宿开支，整体持续15天
手术在上海瑞金医院进行，这家可以说是非常正规的医院了，将整个过程记录下来并总结了部分经验如下

全篇文章分为几个部分：

1. 住院相关
2. 手术相关
3. 家务相关
4. 观察总结

住院相关

住院前准备

1. 手术费几万垫付，现金需准备好，保险至少备5w
2. 取部分现金拿着备用，有些药需要现金
3. 医院食堂饭卡充值+押金，只能现金，100+
4. 工作事宜交接请假处理好
5. 住院大楼的门禁卡办理
6. 是否本地医保，是否驻外医疗，是否可以要开转院证明报销用，上海的是无法开出去外地的转院的

住院事项

1. 各种检查做一遍
2. 病房会给病人提供三餐（医生开的食物，如易消化面条粥之类的）一段饭30元，早上7点送饭，中午11点送饭，晚上4点半送饭
3. 家属可以去隔壁楼食堂吃饭，有粥，面，套餐等，办卡10元押金，充值最低30元，必须现金充值，一次餐饮大约10-25元之间，餐厅开放时间：6点半-晚7点半
4. 病房进出管控严格，一个病人可以有一个家属卡（卡只有1张，病人本身有额外手环标识可以随便进出），持卡人可以在早11点后一直到第二天早上7点可以陪护（早上7点-11点不允许任何人进去，包括持卡人，楼下有家属等待区），下午3点到晚8点为探视时间（不超过3个家属可以不用卡随便进出）
5. 晚上是否可以在病房里？老人可以开个陪床单子只能有1个，什么时候都可以来，非老人则不行，不过可以在7点赶人时偷偷藏到厕所里过会再出来，一般看望的只能11点后进来
6. 持卡人在病房过夜，只有手术期间提供躺椅1张用1晚，手术前不提供，不允许带躺椅，折叠椅进去，如果自己陪护买充气床，如果不想自己可以雇佣护工180白天+晚上
7. 当时在住院楼12层共51个床位，10个床位位于双人房，1个位于3人房，剩余都是4人房，4人房一天50元，2人房很贵一天800元；病房51个，1-6号，42-45是2人房，39-41是3人房，其他是4人房
8. 一般住院检查无误后很快会安排手术

住院每日

1. 每日测体温：耳朵测量体温套不要扔掉，住院期间复用一个，出院再扔
2. 每日换病服
3. 可以换床单
4. 输液-保护胃的，少吃饭，所以抑制胃酸分泌
5. 输液-葡萄糖
6. 输液-氯化钾、氯化钠

物品

1. 护理垫：术后垫上护理垫
2. 唇膏：出来摸嘴唇，不能禁食禁水防止嘴唇干裂
3. 纸巾&卷纸&湿厕纸：上厕所
4. 纸抹布：一次性抹布，擦桌子等物品用
5. 充气床垫180：在医院门口都有必用品购买
6. 饮食用具：水杯，勺子，中玻璃饭盒，保温杯、水果刀、海绵+洗洁精
7. 洗漱用品：拖鞋，牙刷，牙膏，毛巾，2个衣服撑子，3个盆子
8. 生活用品：行李箱，小被子，手机，换洗内衣，医保卡，身份证，现金与银行卡

总结医院的衣食住行用
衣：睡衣，内衣备用，个人衣服1套，拖鞋
食：病人餐饮提供，饭盒，勺子，水杯，餐洗净，其他人办理饭卡楼下吃
住：床被都有，其他人需要小毯子，地铺毯子
行：不需要，门禁卡要有
用：毛巾，盆子多个，衣服撑子，行李箱
用-消耗：肥皂，洗发水，化妆品，卫生纸，抽纸，护理垫，一次性牙刷，牙膏

出院

1. 磁卡，押金单，单子，去下面付钱上来开出院小结
2. 1月后复查，取细胞化验报告
3. 伤口渗黄水说明感染，需要来医院
4. 线可以吸收不用拆
5. 不能重物，但要运动下
6. 术后饮食注意事项，需观察关注的点
7. 洗澡可以用防水贴住伤口
8. 填写护士的满意度调查表

手术相关

术前准备

1. 手术前住院几天责任护士，护士长名字
2. 清理身体：洗澡、划体毛、清理指甲
3. 衣服倒过来，氧气设备准备
4. 吃饭阶段1：饮食不允许吃有渣食物，方便后续手术防止清理不净
5. 吃饭阶段2：术前多少小时禁止喝水吃饭
6. 吃饭阶段3：清肠：舒泰清口服多次
7. 验血、验尿
8. 是否需要送礼

术中

1. 手术7点只能1个家属在病房
2. 手术情况在家属等待区有电子屏

术后处理

1. 护工：刚出院几天要请护工，一天70，预交7天，帮洗漱去厕所，差不多用了4天就可以自己下床走动了，然后退护工钱
2. 不良反应都属于正常：恶心，想吐；疼；头晕
3. 要动动身体，下半夜2次侧身防止肠粘连
4. 晚上家属看守排班，几个亲戚轮流看守：盯吊瓶、扶上厕所、帮吃饭、护士交流、特殊帮忙，如果床位空晚上可以偷偷睡在空床位上

手术事项

1. 病区就是不一帮人，第一病区与第二病区就相当于是两个手术团队
2. 手术开始的很早，第一台7点半，手术时长2-4小时不等，也有更长时间的
3. 周六周日不手术

家里

家务处理

家人亲属衣食住行的安排

1. 定住宿，可以美团

家人住宿物品准备

1. 备用毛巾、酒店备用拖鞋、酒店备用牙刷
2. 卷纸、抽纸、小包纸

医院观察总结

医院部门

1. 员工餐厅与家属分开2个，不在一起饮食
2. 教学，门诊，急诊，行政，餐饮xx楼；教学，门诊占地面积较大
3. 病房楼5大座：普通最高，内科，外科，9舍（有食堂），感染呼吸科的（需要隔离）

其他感受

1. 医院里陪床最讨厌的事情：打呼噜睡不着，连续两天经历打呼噜，一天出差跟同事，接着在医院陪床隔壁也打呼噜，连续2天没睡好
2. 人家说来医院哪有不花钱的，所以该花的花，这种手术有一半进口材料不给报销，剩余报销85%，然后有商保可以再报销剩余15%，所以花钱主要是自费的项目

背景

面对复杂的日常、家庭、工作与学习任务，如果高效管理与执行是一个问题
从学生时代就有记录笔记与任务的习惯，当时主要的手段是记录到本子上，有知识管理的笔记本，自己还管理一个特殊的任务本用于管理任务
后来逐步使用上了一些软件工具去整理任务与知识，当然还有一些梳理知识的工具，这篇文章将会将经历与自己最好用的工具推荐给大家

使用过并放弃的任务与知识管理工具

1. Notepad++
2. Excel
3. OneNote
4. Outlook
5. Mindjet MindManager
6. Gitlab
7. 码云
8. 自建工具
9. 小米记事本

1. Notepad++（任务+知识）

可以说一个记事本可以说是万能的，也是最灵活的
有时候琐碎的知识与任务习惯用记事本记录下来，win用Notepad++，mac用sublime
开启Notepad++的自动保存功能防止丢失
不过不好的是不是实时更新，而且有可能会丢失未保存的信息

缺点

1. 一次惨痛的记录丢失，可能是软件更新还是未开启自动保存，丢失数据
2. 知识无法分类，只能依赖文件夹，也不容搜索

2. Excel（任务）

主要记录任务，不过发现任务关联了图片与知识等非常难搞，而且excel内容多了很卡，启动慢，用起来不爽

3. OneNote（任务+知识）

微软的工具，在Office新版本中自带的
最初还是非常好用的，不过后来放弃了
可以管理任务，也可以管理知识

优点

1. 图片、文档都可以存储
2. 文件一体化，如果想copy，直接复制文件夹，不过新版本强制在云上了
3. 有标记，任务标记，快捷键用起来高效方便

缺点

1. 搜索功能及其难用，尤其是中文搜索，经常分词错误，要么找不到信息，要么找一堆没用的信息
2. 新版本笔记本不能存储在本地了，只能存储在云上，感觉自己的信息泄露
3. 写文档不如md，默认的内容到其他地方剪贴总是转成图片，不爽，有时候copy进来的数据也变为图片
4. 任务管理，没做完的总是要copy各种地方，迁移每日任务很麻烦

4. Outlook（任务）

曾经有一阵使用Outlook作为邮件管理时，重要邮件会标记为任务，然后在任务中管理进度
所以尝试在里面直接添加非邮件的任务当做任务管理，因为里面的任务状态非常好用，甚至用于管理组员的迭代需求
还有一个亮点是与onenote结合，数据可以互通
当时一度感觉onenote与outlook组合可能就是我的最适合工具了，不过后来电脑迁移时发现了各种不好移植的问题，而且与onenote同步也有bug
最终放弃

5. Mindjet MindManager（任务+知识）

当时思维导图用于管理知识是因为记录上面可以携带附件并且标注优先级，在思维导图上非常清晰
不过文件大了会非常卡，放弃
总结的话：思维导图只适合梳理知识并非记录知识与检索知识！

6. 自建Gitlab（任务+知识）

因为在公司写代码时使用Gitlab的issues与wiki功能，十分方便
issues管理任务，wiki管理知识
一开始尝试使用，直接拿第三方的虚拟机镜像启动，不过后来自建Gitlab由于是虚拟机，每次记录非常麻烦遂放弃

7. 码云（任务+知识）

本地虚拟机启动非常蛋疼，但后来采用国内免费代码托管平台码云就不用重启了，每次url输入编写任务
码云提供了附件功能用于可以用于装文档中关联的大文件
项目建立为私有的，这样只有自己能看到内容
如果登录态失效，当前页面内容会自动缓存一份，刷新后再尝试点击保存即可

缺点

1. 自动保存不完善，很容易丢失编写的信息
2. 任务管理上非常的卡顿，慢到想放弃
3. 没有树形结构与层级，无法直观的对issues任务分类
4. 有一次码云更新遇到一个wikibug，我反馈了下结果他们的研发就直接看我项目内容，感觉没有隐私，还是放弃用于知识管理了

之所以想找个云管理就是因为方便，不用装软件就可以记录，不过最终用下来中间容易丢失信息、卡顿、隐私问题是不可容忍的，放弃这种纯云端的
总结来看这类代码托管的需求知识管理，主要是团队协作才需要，如果只是一个人用的话完全没必要把简单事情复杂化，后面在选择上放弃全部在线类的应用

8. 自建工具（任务）

对于任务管理我想要的工具是每天都能告诉我今天什么最重要，要先干什么事情
于是在多个工具无法满足后我决定自建工具，开发一个web程序
于是我做了一个导航式的页面，数据库中维护了我的每天、每周、每月要做的任务，然后每天都展示最新的
不过数据我就自己在代码中维护了，一开始还好，觉得很满意，不过有一段时间没用，发现难以维护，最终放弃了使用
不过这个项目有个副产物：公司需要一个导航系统输出各个基础平台的产品，我直接开源贡献出来好评如潮 =。=

9. 小米记事本（任务+知识）

手机上也会记录下灵感、思考与任务，就用了手机自带的，由于有云同步也是比较好用的，可以在电脑上编辑
最大的好用点是：APP打开极快
缺点：早期经常丢失内容，小米客服与程序员一直说没bug，但实际会发生感觉累觉不爱，不过后面改为重复不丢失了，不过经常网络不好就重复一个片段
还有就是手机空间不够时不会云同步非常蛋疼，每次想PC要同步数据还要清理下磁盘，简直妨碍使用，放弃

总结之前产品经验与实际需求

数据流向的思考

记录/任务–>知识梳理
知识梳理–>扩展知识

知识沉淀，大部分起源出自每日做事情的总结与思考，所以每次做完的任务也不能立马删除忽略，还要进行一定总结思考然后彻底关闭

工具需求

在经历了数据丢失，维护麻烦，卡顿低效，搜索不好用等经历
制定了工具的要求：必须是客户端工具带有强大的搜索功能、可以自动实时存储本地、异步远程同步、可以保存历史版本

最终我找到了一套符合自己的组合可以满足需求

最终程序员工具组合

这组工具的前提是：程序员会使用idea、mac电脑

任务分类与对应工具

1. 紧急任务：手机日历、手机闹钟
2. 琐碎记录/采集：有道云笔记：PC、手机都安装
3. 任务：OmniFocus，其实我想自建的工具的功能就是这款应用！
4. 知识：logs项目@idea，记录在hexo的博客项目中，markdown编写
5. 知识梳理：Xmind思维导图、Mindjet MindManager
6. 公开知识：自建博客、简书、其他技术博客、公众号

1. 有道云笔记

有道云笔记有多个端：手机、PC、网页，同时可以有多种工具采集，容易多端去操作一些琐碎的任务与记录，格式多种
其实我用云笔记也没多久，最初用码云时我就感觉其实国产软件最好的点就是针对国人的习惯会定制化一些功能会非常好用，而且迭代速度非常快，所以笔记类的还是想尝试下国产
至少onenote的搜索与粘贴实在是太蛋疼了，云笔记目前用下来感觉还是不错的

2. IDE-idea

知识需要很好的展示统计也需要存有历史与检索功能，我目前用的最好的检索工具就是idea的代码检索，而历史版本管理最好则是git，好看与统计就用hexo博客的功能

1. 当然有道云笔记也可以做一些，不过我更想让知识可控一些，并且知识形成主题会发布博客，所以在本地管理总结也是非常方便的，这种总结一般都在PC上做，并且有些信息也是保密的，不适合存储云端
2. 知识需要Tag功能，一偏文章有很多Tag要打，用hexo的Tag功能很方便
3. 图片使用了新浪图床，chrome小插件搞定
4. idea的自动保存功能保证了数据不丢失
5. 本地IDE还方便搜索支持正则胜于onenote与wiki：胜于2者，查找方式非常灵活呀
6. 2下shift直接定位这种文件操作
7. 写文章还可以用各种快捷键与vim编写，就像写代码一样，想多快有多快！

现在想来最好的文本管理工具当然是程序员用的IDE了，代码也是文本，拥有价值，集成各种版本管理与查找功能，如此复杂的工程都可以管理，就何况自己的知识管理了

3. OmniFocus

用了Mac后发现了任务管理的神器：OmniFocus，这东西完全满足我自研项目的功能，展示当日任务，同时还有上下文的设计，非常喜欢
推行GTD理论，这个可以说是任务管理的最佳实践，此工具真的是深得我心
有一个自由任务收集的地方，也有项目形式的，感觉与做软件项目比较像
所有任务用4象限规划好，先做哪两个象限的事情要清楚，重要紧急，重要不紧急最优先，紧急的可以再往后，否则重要的事情总是被耽误。
而OmniFocus提供了一个标记重要事件的视图，可以看到哪些是最重要的事情，可以安排上时间与上下文

任务管理方式：GTD理论与工具

1. 尽可能的收集任务，全部罗列出来
2. 设定上下文场景与时间与优先级
3. 日历安排
4. 回顾完成任务

OmniFocus学习

1. https://support.omnigroup.com/documentation/omnifocus/mac/2.3/zh/projects/#projects
2. 上下文：位置、人员、物品

4. 思维导图

知识碎片在变为知识时需要梳理，梳理用思维导图最好不过，目前免费好用的也就是Xmind了
不过Mindjet MindManager我最喜欢，不过是收费的

总结

在用电脑时记录大多都保存在记事本中，直到工作之后知识多了起来需要逐步管理与总结才开始挖掘工具的使用
最初用的最多的就是OneNote了，我的很多记录还都在那里面
从最初11年使用OneNote到现在最佳实践的搭配，基本上也摸索了6、7年了，这些记录真的可以说是伴随我工作的第二大脑了
对于我这种强迫症来说，使用过这么多工具其实中间经历过好多次笔记的迁移工作，现在想想真的是蛋疼，不过每次迁移笔记都是一次过滤与回顾，时间花的也算有些价值

目前的这套搭配非常适合程序员，对于不要求那么灵活与非程序员来说可能有道云笔记or其他笔记软件就比较适合，这里只是展示给大家一些个人使用心得吧，希望对大家有用！

参加漫展

1. 12月16日：CP23

CP23感悟

趋势

1. 游戏，手办，周边杂货，虚拟偶像（好赚钱？）
2. 女性向游戏不少，看到有5个，都是男人的游戏

参加这次CP，感觉短短半年女性向ACG突然崛起了，随便逛逛开发商手游就见到5、6款，是男性向的钱被榨干还是市场不景气大家都开始扩大用户群了[流汗]

小裙子（有美女cos），cos化妆品，假发

艾漫，微笑社

emefans？人好多
杨天翔？

猫耳app平台，广播剧？？

现在体验好，不过想要的主题无法搜索，其实只想逛自己感兴趣的部分，其他新奇的也可以看看，做线上下结合才行，目前太累

千篇一律，不如自己定制什么样的图片，有图片库就好了

做一个二次元同人物品网站，物品方便搜索与定位

tap与bili现在刚需，家家需要关注预约！

感觉本子少了，周边特别多，重复的物品类型

神乐坂真冬！写真

随直播赚钱还在cp卖自己的写真

现在盖章了，真麻烦

漫展人多，怎么容纳呢，要验签票，卡，所以为了提高吞吐量不至于在门口阻塞导致请求拒绝，在里面增加蛇行栅栏，同事设定vip请求直接进去，这样提高了吞吐量，不过队列会占用一部分内存场地而已

验签与拦截，先验证行李（安全检验），多并发入口，里面再去验签票

bili会员购有专门票验票地点

刺客五六七