我之前在跑 rsync+innotify 做備份。
後來換了 nfs 盤，innotify 無法補抓變動，
就改為腳本寫 tar 備份到本地，然後靠雲服務商的快照來備份

tar+gzip 不是能達到你要求嗎

@ukipoi 有點牛角尖了吧...
第一步，必須是查班級有沒滿，滿了就丟去另一個班。返回班級 ID。
第二步，把第一步返回的班級 ID 記錄進學校的表裡。

你的條件是：
學生必須綁定班級才算本校學生。
班級滿了開新班，但不限數量。

所以根據條件，流程自然是先檢查班級人數是否滿再做對應業務邏輯。
第二步是把第一步的班級 ID 記錄進學校裡，
最後得出的結果就是這個學生是 XXX 班 XXX 學校的學生。

A.ID 對應 B.AID 就註定了是必須先有 A 才有 B。

@ganbuliao 侵犯了別人的隱私。
打比方你在高仿 TAOBAO 上用 100 買了個充氣娃娃。
雖然店鋪是騙子，肯定不給你發貨。
此時你的損失是 100 和個人資料。

但是有人入侵查看了資料；
你的損失是 100 和個人資料*2。

說句不好聽，你怎麼知道他沒收集別人的資料？誰作證？
現在 JC 執法都要攜帶警視錄像。

@lysS 別忘了定義是否自衛的權利不在自己手上。
而且自衛前提是人生命受到威脅時。
和題主所說的情景不一致吧。

只能說這樣做 在道德上是正確的，但法制上是錯誤的。

我記得有個題目是：
5 個小孩子在一條廢棄鐵路玩，但是有一天，其中一個孩子玩厭了跑去旁邊新的鐵路玩，並且叫了剩餘的孩子過去。
但是其中有一個孩子知道那樣危險，所以不過去，剩餘的都跑過去在用的鐵路上玩了。

突然有一台火車行駛過來，
如果您是鐵道控制員，
你把鐵道打到廢棄的鐵路上，只會犧牲一個孩子；
不把鐵道打過去舊鐵路，那麼新鐵路上的 4 個孩子全都會死。

你會怎麼選擇？

MYSQL 的 JSON 形式我沒用過，不知道如何，所以不敢給建議。
但是你可以再後端把數組轉為字符，用逗號分割。
使用的時候通過 find_in_set 來查找。

但是記得，find_in_set 裡面不要再套子查詢，否則性能能讓你哭.

1、mysql 新版本支持 JSON 查詢
2、在不支持 JSON 查詢的 MYSQL 裡，為什麼要 JSON 形式保存結果，改為 12,14,121 這樣插入不行嗎？
如果是 12,14,121 這形式插入，直接用 FIND_IN_SET 來查找即可了。

@kayseen

比如现在有两张表,分别是 class 表和 studend 表,
:有兩張表

现在两张表都是空的,并且在 student 表里面有一个字段是 class_id
:裡面一個字段叫 class_id

两张表需要同时新建一条数据: class1 和 student1,
:無法理解同時插入 class1 和 studen1 數據，畢竟上面沒提過字段，唯一字段是 class_id，這行自行腦補為各插入數據

并且 student1 的 class_id 字段需要指向 class1 的 id,
:student1.class_id 對應 class1.id;(上面表名是 class 和 studend 這裡就變了，也自行腦補算了。)

请问这种场景应该怎么实现才能让他们保持一致性,并且 student1 的 class_id 可以指向 class1 的 id?
:如何保持 student1.class_id 對應 class1.id 的關係。

因为 class1 没有保存的时候,是没有 id 字段的,
:那如果先保存 class1 會導致什麼後果？

还是说这种场景下不能保持一致性啊
:請問你試過了嗎？自己試出來的才是真諦。


另外，
不是事务之后会有数据的 id，
你只要 ID 是使用 AI 的，插入後都能獲取自增 ID。
事物的開啟是為了保證第二句插入的時候有意外能把第一步的操作取消了(回滾)。


最後，我語言可能有些偏激。
我意思是如果你非新手問這樣的問題，你技術道路基本是走到盡頭了。

@ddosakura 问题是谁来定义钓鱼网站和诈骗网站？
打个比方，坏人都该打。但如果三五成群就指认别人是坏人，直接打，那不就又跑回四人帮的那年代吗？
我是支持 @ceet 的说法，
但我觉得可以适当量刑。
另外，这些本事某些收着高额保护费要求等保的 GA 单位做的事情，他们也应该定责吧？(如果境外网站那当我没说这句)

別來騙代碼，如果連這也偷懶，你技術的道路也走到盡頭了。
如果你是剛學，那給思路你沒問題。
開啟事物。
插入 class 表，獲取 insertid。
插入 studend 表
任何一部出錯，都 rollback，
成功都 commit。

這些 2、3 線部門，自己本來就沒預算，能出來就算好了。
@ddzzhen Z,F 部門和單位給的價格也是一坨屎一樣。
其實拋開預算，Z,F 單位的基本都是走形式，如果他們真的有人自己看一眼，肯定抓開發公司整改。
這些說白了，要麼上面有文件下來，要麼自己想搞點政績。真心為群眾？

話說，某地的科信局技術總工程師，文檔能力十分強悍，找第三方做了個類博客宣傳站點，他足足寫了十多頁的工作報告。

你可以參考下：
前端靜態，丟 CDN。
兩個前端頁面，一個是發無效請求去百度，一個是發有效請求到 java
然後有效請求的那個頁面，發送 ajax 去 java 第一輪按百分比返回結果，
50%以上執行上面搶購邏輯。50%的就直接返回失敗。

當然，這是很低莊的方法，但一定程度內有效分流，也能保證到超售情況。

@yejianmail 你可以做個頁面，一有請求就減庫存，按照我上面那個方法，然後 ab 測試一下，看看會不會出現超售。
反正超售是肯定可以保證，但是由於執行流程是一個個執行，所以後面的並發會卡在那，此時前端 ajax 設置個超時重試參數。
另外流量真的大，你直接後台按百分比來放行，比方隨機 1~100，只要是 50 以上的放行進行搶購，50 以下的直接返回失敗。

你買的域名再騰訊，你買的機器再阿里。
備案時候在阿里進行，不是在騰訊進行。

@markgor #30 select 1 from item where id = 123 and less > 0;沒記錄就返回失敗
update item set less = less -1 where less > 0 and id = 123;影響條數=0 返回失敗

臨時寫的，上面寫錯了，這更改回來。

一个用户不太多的秒杀 還能出現-1 的情況....


我通常偷懶的做法

start transaction;
select 1 from item where id = 123 and less > 1;沒記錄就返回失敗。
update item set less = less -1 where less > 1 and id = 123;影響條數=0 返回失敗
commit;

還未出現過超售。對了 item 的 less 是不允許負數的。

另外也試過 redis 預熱，
把獎品加進去 redis，
然後成功 pop 出來再去 mysql 扣減。

@markgor #23 <---請忽略，
打 1 萬，可以申請免 CGN，問為什麼就說監控用到。一般 24 小時內會開通，開通後不會再被 CGN 了。

“被重拨”没收公网 IP
據我所知廣東電信默認 48 小時就會斷開一次。其他地方估計差不多。
難不成你覺得動態 IP 是根據你撥號後不斷線就不更換嗎......

好奇這些資料的來源.....