可噴
一些標籤應用的場景的現狀：
1.作爲一個獨立的應用系統維護，但成本高，不易維護
2.標記，多數僅是微小的變化，跟隨每條記錄，場景較少，量大
3.獨立標記的維護，比如redis，定期同步到存儲，但一旦丟失，對下游系統影響較大
。。。
總的來說，就是沒tag也不方便，但有tag偶爾要維護那麼幾下或作爲低頻的維護，又有點麻煩，那有沒一種不需要大量update呢？
比如通過棧模式設計（也有點像波蘭表達式），類似只+不-的做法（對於一些標籤應用，實際操作可能要複雜些，配合中間件應用或許效果更好）
----總結1
A.標記不能獨立，還是跟着DB走，對於更新問題，可以選擇一些成本開銷較小的策略，比如下列方案，類似棧結構
{
"stackName#0#tagName":{"id":"tagName","startT":1574661706330,"v":true}"skLen":0,
}例,xx項目，審覈通過標t_audit_yes
{
"10172030112001#0#t_audit_yes":{"id":"t_audit_yes","startT":1574661706330}
}
,然後流程異步通知爲審覈中t_audited_to_process
{
"10172030112001#0#t_audit_yes":{"id":"t_audit_yes","startT":1574661706330,"v":true,"skLen":1},
"10172030112001#1#t_audited_to_process":{"id":"t_audited_to_process","startT":1574661706330}
}
，再次異步通知爲審覈不通過t_audit_no
{
"10172030112001#0#t_audit_yes":{"id":"t_audit_yes","startT":1574661706330,skLen":1},
"10172030112001#1#t_audited_to_process":{"id":"t_audited_to_process","startT":1574661706330},
"10172030112001#2#t_audit_no":{"id":"t_audit_no","startT":1574661706330}
}
簡單僞代碼：
※若同一個組有存在多個不同釋義的tag，建議組名分開
※棧名，用6位日期+ipV4 9位+自增3位，保證不重複取棧名：
if 標籤元數據 constains 目標元數據
獲取對應stackName List
sort stackPosition
prepare 目標元數據結構
append 目標元數據
end