1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
| Linux：
shred -u 粉碎，彻底删除
删除服务器日志，需要history -c
vm.swappiness可以设置虚拟内存的使用优先级，默认是60，可以调整到10
Python：
selenium+phantomjs抓取网页数据
网络：
可用ip的计算，关键看掩码：
比如22掩码：11111111 11111111 11111100 00000000
添加路由：
route add -host 192.168.1.1 gw 192.168.0.1
route add -net 192.168.4.0/22 gw 192.168.0.1
三类内网IP：
10.x.x.x
172.16.x.x至172.31.x.x
192.168.x.x
我们公司的内网限制规则：
"127.0.0.1/32",
"10.0.0.0/8",
"172.16.0.0/12",
"115.238.33.162/32",
"124.160.30.178/32",
"192.168.0.0/16"
traceroute的星号代表尝试网关超时了，每个网关默认尝试3次
数据库：
主从延时，要看iowait，只要有wait，就是有问题的，说明io达到瓶颈了
安装mysql，在联网的情况下，并没有那么复杂，而且用官方的bundle方法，更是相当便捷
物理机和虚拟机上的MySQL，性能差异是非常大的，特别是IO这块
主从同步的binlog日志格式之mixed：
如果sql中包含一些变量信息，则会采用raw；否则采用statement
比如：
update table1 set mtime=current_timestamp()
这个语句采用了变量(函数)，所以生成的binlog会采用raw格式，确保主从的mtime时间一致
update table1 set isvalid=1 where type =2
这个语句不涉及变量，如果采用raw，可能binlog会有N条记录；为了精简binlog，会采用statement格式
Git：
搭建自己的http协议的git服务器
创建分支：git checkout branchName
回滚/回退：
git reset --hard hashVersionString
git push -f origin master
Javascript：
async function返回的就是一个promise对象
awati后面跟的必须是一个promise对象
业务：
后台现在有多个分级：adm->临时vis后台->CBAS后台
代码检查插件并不慢，svn提交时，慢在其他地方，还没定位到
代码检查通知邮件，在post-commit插件中
做事方法：
先别说搞不搞得完，我们先看怎么样能够比较简单的搞定
怕事者不可成事。做错不可怕，错了才能知道什么是对。
架构师的职责：将复杂的事情，通过简单的方法做成。
想一口学好某个技术是不可能的，这是一个持续的过程，但是我必须通过复习，保证学过的都记住，否则会一直处于学习-忘记的死循环中
三思而后行，尽量少犯错，否则会缺乏信服力
睡眠时间多了并不会带来好处，同样困；因此每天足够8小时即可，保证质量
方案设计能力
久了不敲代码，思维很死了
用双手解放双手，用双手创造更大的价值，放心的将事情交给程序去做，程序比人可靠
mysql掌握不扎实，特别是各项配置
每一个想法都值得被尊重，每一个成事的人都值得被尊敬
做事要像下棋一样，多想几步，这样才不至于恍惚
管理：制定方案、分发任务、跟踪进度
做一件事情，就要做完，不要东一搞西一搞
团队：
我们的架构如果能支持自动伸缩，能承受的并发量就可以大幅度提升了
现在其实我们的服务器，资源利用率非常不均衡，忙的很忙，闲的基本上全天负载趋于0
我们的业务，并发量压力太小，也没有投入太多精力去研究这块
感觉技术的发展还是和业务关联太紧
像SNS、网站，他们的精力大量投入在性能上；而我们的精力，则是投入在快速开发上
都是业务特性驱动的
计划：
1.学会前端开发
2.学会移动开发
3.脱离文档编程
4.学习Markdown
5.通过编写框架来解决业务问题，自我提升
Nginx：
代理https很简单：
location ~* /hexin-crm {
proxy_pass https://172.20.200.8:8002;
}
注意proxy_pass末尾不能有斜杠
经典介绍：
基本语法：location [=|~|~*|^~] /uri/ { … }
= 严格匹配。如果这个查询匹配，那么将停止搜索并立即处理此请求。
~ 为区分大小写匹配(可用正则表达式)
!~为区分大小写不匹配
~* 为不区分大小写匹配(可用正则表达式)
!~*为不区分大小写不匹配
^~ 如果把这个前缀用于一个常规字符串,那么告诉nginx 如果路径匹配那么不测试正则表达式。
示例
=====
location = / {
# 只匹配 / 查询。
}
location / {
# 匹配任何查询，因为所有请求都已 / 开头。但是正则表达式规则和长的块规则将被优先和查询匹配。
}
location ^~ /images/ {
# 匹配任何已 /images/ 开头的任何查询并且停止搜索。任何正则表达式将不会被测试。
}
location ~*.(gif|jpg|jpeg)$ {
# 匹配任何已 gif、jpg 或 jpeg 结尾的请求。
}
location ~*.(gif|jpg|swf)$ {
valid_referers none blocked start.igrow.cn sta.igrow.cn;
if ($invalid_referer) {
#防盗链
rewrite ^/ http://$host/logo.png;
}
}
HTTP：
Node发送http请求时，POST请求头必须有Content-Type和Content-Length属性，否则会请求失败
Node:
promise不能直接调用，必须封装到函数中，调用函数
重复require，是不会重复加载文件的，会直接读取内存缓存，因此可以放心require
|