1. 如果是阻塞式的，那只能代表數(shù)據(jù)已發(fā)出去，但不能保證對方已收到；如果是非阻塞式的，select到OP_WRITE就說明數(shù)據(jù)已發(fā)出去；無論哪種方式似乎都無法確保對方收到，除非對方用數(shù)據(jù)來應(yīng)答；
2. 對方宕機（或者拔網(wǎng)線），理論上我方是無法知道狀態(tài)的，如果對方進程被kill掉，那么操作系統(tǒng)可能會給回一個FIN或RST，你應(yīng)該會select到一個OP_READ，并在read時得到-1或異常。

內(nèi)容可以隨便填，一般是隨機字符串。作用是用來加密cookie

n does not work on Windows at the moment. Pull Requests are appreciated
n 不支持管理 win 上面的 node 版本

UserSerializer里的owner應(yīng)該在SnippetSerializer中吧

你可以在控制臺或者代碼里window.open一下,我測試了下谷歌沒問題..

解決了 把證書換成 https://dash.cloudflare.com/ 就好了

解決辦法：64位系統(tǒng)

[root@ richie]# ln -s /usr/local/lib/libpcre.so.1 /lib64
[root@ richie]# /usr/bin/uwsgi --ini /usr/local/nginx/conf/uwsgi.ini
[uWSGI] getting INI configuration from /usr/local/nginx/conf/uwsgi.ini

nginx
jenkins

Xshell is not a shell/simulator terminal, it's just wrap the CMD.
Find is not available on native windows, but you can download it yourself FindUtils.

registry=http://xxxx:port/repository/xxxx
@namespace:registry=http://xxxx:port/repository/xxxx

建議
1.重新建立從服務(wù)器 （注意克隆主服務(wù)器時 建議刪掉data文件夾中不必要文件）
2.啟動從服務(wù)
3.新建DB
4.導(dǎo)主服務(wù)數(shù)據(jù)
5.設(shè)置主從
。。。

httpd.conf文件里有個配置項

<Files ".ht*">
    Require all denied
</Files>

添加一個

<Files "buildinfo.txt">
    Require all denied
</Files>

即可

__config.yml 配置：

deploy:
  type: git
  repo: ubuntu@xxx.xx.xx.xx(ip):/var/repo/hexo_static
  branch: master

同時git 配置了hooks 指向Nginx的 root 目錄,提交時提示：Everything up-to-date

我認為應(yīng)該是 git 暫存的問題，應(yīng)該是 hexo d 這個命令的執(zhí)行過程的問題，具體我沒搞明白。

最后想了個笨辦法，init 一個新的工程，然后把原來的文章配置等覆蓋過來，然后提交能夠解決問題。

n 是不支持Windows系統(tǒng)的，nvm 也一樣不支持。Windows系統(tǒng)推薦你用 nvm-windows 控制 node 版本：https://github.com/coreybutle... ，安裝及使用參考官方文檔即可。

不考慮IO的話，只要不寫一些作死的邏輯，php的在cli的處理能力基本不需要擔(dān)心不夠用，但是存在IO的情況下，瓶頸大多都是在這些IO操作和等待上，不好給你的數(shù)值。
php的配置一般改動也不會太多，cli下運行主要注意下可以使用的最大內(nèi)存。
增加多個php腳本是可行的，監(jiān)控下CPU和內(nèi)存的使用就可以了
官方文檔有簡要描述，但是看你的這個場景，你不考慮使用 swoole或者workerman這類異步、并行、高性能網(wǎng)絡(luò)通信引擎嗎？

找了一些內(nèi)容來：

3.14內(nèi)核新增了一個內(nèi)存信息MemAvailable , 當調(diào)用free命令時可以顯示為available
之前沒留意過

[root@VM_167_46_centos etc]# free -h
                         total         used             free      shared     buff/cache      available
Mem:           993M        253M        334M         39M               405M             556M
Swap:           2.0G          82M             1.9G

我們知道used + free + buff 基本等于 total

• used是被使用的
• free是完全沒有被使用的
• shared是被程序之間可以(已經(jīng)被)共享使用的
• buffers是指用來給塊設(shè)備做的緩沖大小，它只記錄文件系統(tǒng)的metadata以及 tracking in-flight pages
• cached是用來給文件做緩沖

也就是 buffers是用來存儲目錄里面有什么內(nèi)容，權(quán)限等等。而cached直接用來緩存我們打開的文件
available到底是什么

Many load balancing and workload placing programs check /proc/meminfo to estimate how much free memory is available. They generally do this by adding up "free" and "cached", which was fine ten years ago, but is pretty much guaranteed to be wrong today.
It is wrong because Cached includes memory that is not freeable as page cache, for example shared memory segments, tmpfs, and ramfs, and it does not include reclaimable slab memory, which can take up a large fraction of system memory on mostly idle systems with lots of files.Currently, the amount of memory that is available for a new workload,without pushing the system into swap, can be estimated from MemFree, Active(file), Inactive(file), and SReclaimable, as well as the "low"watermarks from /proc/zoneinfo.However, this may change in the future, and user space really should not be expected to know kernel internals to come up with an estimate for the amount of free memory.It is more convenient to provide such an estimate in /proc/meminfo. If things change in the future, we only have to change it in one place.

也就是說available才是你的"可用內(nèi)存" , 而不是像過去那樣簡單的把free和buffer加起來

available 小于 free+buffer 是一定的了

這個丟到 vhost 就可以了。

先把腳本設(shè)置可執(zhí)行權(quán)限，

chmod +x bash.sh

然后扔到 etc/rc0.d 中

cp bash.sh /etc/rc0.d/

rc0.d 存放的是關(guān)機前執(zhí)行的腳本
rc6.d 存放的是重啟前執(zhí)行的腳本

'accept-encoding': 'deflate, br',
你把這個去掉，就返回正常了；你現(xiàn)在這個是返回的是壓縮了的，除非你讀取響應(yīng)頭，看看服務(wù)端到底使用何種壓縮算法，進行解壓。

運行命令試試呢：

sudo brew uninstall pcre
sudo brew uninstall nginx
sudo brew install nginx