很可惜 T 。T 您現(xiàn)在還不是作者身份，不能自主發(fā)稿哦～
如有投稿需求，請把文章發(fā)送到郵箱tougao@appcpx.com，一經(jīng)錄用會(huì)有專人和您聯(lián)系
咨詢?nèi)绾纬蔀榇河鹱髡哒埪?lián)系：鳥哥筆記小羽毛（ngbjxym）
這是彭文華的第92篇原創(chuàng)
一直想寫一篇大數(shù)據(jù)計(jì)算引擎的綜述，但是這個(gè)話題有點(diǎn)大。今天試試看能不能一口氣寫完。沒想到一口氣從7點(diǎn)寫到了凌晨2點(diǎn)
大數(shù)據(jù)計(jì)算的起點(diǎn)是Hadoop的MapReduce。之前雖然有一些分布式計(jì)算的工具，但是公認(rèn)的大數(shù)據(jù)計(jì)算引擎的始祖仍然是MapReduce，雖然現(xiàn)在已經(jīng)逐漸被同是批處理的Spark替代了。如同MapReduce一樣，Storm開啟了流式數(shù)據(jù)處理的先河，現(xiàn)在也被如日中天的SparkStreaming完全替代。而Spark和SparkStreaming的前面，正有一顆冉冉升起的閃耀巨星-Flink。
我當(dāng)年在做某市交通委項(xiàng)目的時(shí)候，用的是Oracle。數(shù)據(jù)就是從各個(gè)收費(fèi)站、路網(wǎng)上Socket過來的每輛車輛監(jiān)測數(shù)據(jù)，一天數(shù)據(jù)量好幾百萬。這個(gè)數(shù)據(jù)量現(xiàn)在看好像沒啥，但是放在2013年就蒙圈了，那時(shí)候還在用Oracle。作為單體數(shù)據(jù)庫管理系統(tǒng)，Oracle其承載能力是有限的，基本上一個(gè)月的數(shù)據(jù)就能撐爆了。單表2000萬性能就明顯下降，軟件層面優(yōu)化無望，只能寄希望于更好的硬件--小型機(jī)。當(dāng)時(shí)的業(yè)界基本就是這個(gè)狀態(tài)。
這個(gè)時(shí)候，Hadoop攜MapReduce橫空出世！google實(shí)驗(yàn)室發(fā)明了MapReduce和Google File System，Apache基金會(huì)的人大受啟發(fā)，成功孵化了Hadoop項(xiàng)目。
單體數(shù)據(jù)庫能力有限，最后只能期望硬件（CPU、內(nèi)存）越來越強(qiáng)，相當(dāng)于是追求個(gè)人武力值的不斷超越。而Hadoop生態(tài)的核心是化整為零，分而治之。Hadoop可以將一個(gè)巨大的數(shù)據(jù)集進(jìn)行切分，然后分發(fā)給N個(gè)機(jī)器上進(jìn)行存儲(chǔ)，執(zhí)行計(jì)算任務(wù)時(shí)，Hadoop將MapReduce任務(wù)扔到存有數(shù)據(jù)的N臺(tái)服務(wù)器上，各自執(zhí)行Map和Reduce過程，最后匯聚成為最終結(jié)果。
單臺(tái)機(jī)器的進(jìn)化有極限，而且成本會(huì)越來越高。而Hadoop的“分而治之”的思路完全打破了原有的單兵作戰(zhàn)的套路，實(shí)施蜂群戰(zhàn)術(shù)，讓算力和服務(wù)器資源的線性增加成為可能。需要提升算力，只需要投入基本等同的普通計(jì)算機(jī)即可。
當(dāng)時(shí)我們就用Hadoop的早期版本成功解決了交通項(xiàng)目數(shù)據(jù)海量線性增長的問題。對(duì)的，那時(shí)候還不叫“大數(shù)據(jù)”，叫“海量數(shù)據(jù)”。
MapReduce為了提升效率、增強(qiáng)魯棒性，做了大量的精巧設(shè)計(jì)。比如為了解決Java的Full GC的問題，設(shè)計(jì)了環(huán)形緩沖區(qū)，以減少大量的內(nèi)存申請和廢棄操作；為了提升速度，在Map階段做了大量的排序，Reduce階段獲取的數(shù)據(jù)天然有序，計(jì)算速度得到極大的提升。
MapReduce擴(kuò)展閱讀：
點(diǎn)擊閱讀：架構(gòu)師帶你細(xì)細(xì)的捋一遍MapReduce全流程【附調(diào)優(yōu)指南】
點(diǎn)擊閱讀：設(shè)計(jì)思想賞析-MapReduce環(huán)形緩沖區(qū)
雖然MapReduce是創(chuàng)始者，但是有各種問題備受數(shù)據(jù)工作者詬病。比如Hadoop源碼是用Java開發(fā)的，抽數(shù)得寫Java程序，數(shù)據(jù)工作者還得學(xué)Java；最令人忍受不了的是每次都要落地，一旦DAG較長，速度將變得無法忍受；還有就是基本都是T+1，不能實(shí)時(shí)出結(jié)果。
所以業(yè)界也在不斷地研究如何提升效率。當(dāng)時(shí)有兩個(gè)主流發(fā)展方向：
提升速度；
追求實(shí)時(shí)。
Spark和Storm就是在這種狀況下被發(fā)明出來的。加州伯克利大學(xué)AMP實(shí)驗(yàn)室選擇的是提升計(jì)算速度的方向，他們想要發(fā)明一個(gè)比Hadoop快N倍的分布式計(jì)算引擎。他們做到了，這就是Spark！
MapReduce之所以慢，就是因?yàn)橐ＷC集群的容錯(cuò)，因此所有操作結(jié)果都要落地一次，這個(gè)大量的磁盤刷寫過程非常耗費(fèi)時(shí)間。那么Spark的解決方案就出來了：所有操作都在內(nèi)存里進(jìn)行，沒有了磁盤刷寫，效率自然要高無數(shù)倍。
Spark把處理的數(shù)據(jù)集取個(gè)名字叫做“RDD”，即Resilient Distributed Datasets彈性分布式數(shù)據(jù)集。把計(jì)算邏輯抽象好，取個(gè)名字叫“算子”。整個(gè)計(jì)算過程就是輸入-過濾算子-map算子-匯總算子-輸出。
如上圖所示，整個(gè)計(jì)算過程的所有數(shù)據(jù)全程不落地，減少了MapReduce無數(shù)次的磁盤刷寫過程，效率自然百倍的提升！
但是這么做有一個(gè)風(fēng)險(xiǎn)：因?yàn)閿?shù)據(jù)都在內(nèi)存里，一旦某臺(tái)機(jī)器掛掉，就會(huì)導(dǎo)致該節(jié)點(diǎn)所有流程數(shù)據(jù)全部廢掉。所以Spark的Task有一個(gè)“推測執(zhí)行”的機(jī)制，一旦發(fā)現(xiàn)你這個(gè)機(jī)器因?yàn)槟承┰?，沒有在預(yù)定時(shí)間內(nèi)反饋結(jié)果，則在集群內(nèi)有同樣數(shù)據(jù)的節(jié)點(diǎn)上再起一個(gè)相同的任務(wù)，同時(shí)跑，哪個(gè)先執(zhí)行完，就用那個(gè)結(jié)果。而且RDD本身也能借助RDD的血緣關(guān)系lineage graph機(jī)制避免重新計(jì)算，一旦某個(gè)RDD計(jì)算時(shí)掛了，其他節(jié)點(diǎn)不用重新計(jì)算，繼續(xù)接力跑就可以了。
至于Twitter開源的Storm，它有一個(gè)別稱：實(shí)時(shí)的Hadoop。是的，Storm選擇了另外發(fā)展方向：實(shí)時(shí)數(shù)據(jù)處理，它選擇來一條數(shù)據(jù)處理一條數(shù)據(jù)。因此它的延遲非常小，但是可以想象，吞吐量肯定出問題。
而Storm對(duì)于數(shù)據(jù)消費(fèi)的態(tài)度是不丟就好，一旦發(fā)現(xiàn)數(shù)據(jù)丟了，就重新再來一次。
但是！如果這個(gè)時(shí)候原來的數(shù)據(jù)沒丟，只是網(wǎng)絡(luò)延遲，那么這個(gè)數(shù)據(jù)就會(huì)重復(fù)計(jì)算。這個(gè)毛病直到現(xiàn)在都沒有太好的方法解決，也是諸多使用者極為詬病的地方。
另外一個(gè)飽受詬病的地方是它的語言。Storm使用一種極為偏門的語言，用戶體驗(yàn)非常不好，所以SparkStreaming一出，立刻就擠占了Storm的市場。
Spark擴(kuò)展閱讀：
點(diǎn)擊閱讀：12種方法，徹底搞定Spark數(shù)據(jù)傾斜！
Spark獲得成功之后，AMP實(shí)驗(yàn)室并沒有停下腳步，他們也開始選擇另外一個(gè)方向進(jìn)行突破：實(shí)時(shí)計(jì)算！
不得不說慣性思維很恐怖， 即便是AMP如此聰明的大腦們都飽受其影響。從SparkStreaming的設(shè)計(jì)理念上就能看出Spark的影子。雖然SparkStreaming被歸類于流式數(shù)據(jù)處理引擎，但是嚴(yán)格來說，它其實(shí)是微-批處理。這個(gè)其實(shí)源自于各個(gè)開發(fā)團(tuán)隊(duì)對(duì)于數(shù)據(jù)顆粒度的認(rèn)知，如同物理學(xué)上對(duì)光是粒子還是波的認(rèn)知一樣。
AMP認(rèn)為流式數(shù)據(jù)其實(shí)是連續(xù)的，因此認(rèn)定"流是批的特例"。那么流式數(shù)據(jù)的計(jì)算就是將連續(xù)不斷的批量數(shù)據(jù)進(jìn)行持續(xù)的批計(jì)算，如果把批量數(shù)據(jù)切分成足夠小的DStream，那么就是實(shí)時(shí)了。
這個(gè)設(shè)計(jì)給SparkStreaming帶來了非常優(yōu)秀的特性：
比Storm更高的吞吐量，不是一條一條，而是幾條幾條的處理；
失敗恢復(fù)超快，因?yàn)槎际切∨臄?shù)據(jù)計(jì)算，失敗了干掉就好了；
與Spark幾乎一樣，數(shù)據(jù)工作者只需要搞定一套 ETL 邏輯就能同時(shí)搞定跑批和流式計(jì)算。
而Spark+SparkStreaming的組合，也成為了近幾年的業(yè)界主流，這種批、流分開設(shè)計(jì)的架構(gòu)被成為Lambda：
SparkStreaming擴(kuò)展閱讀：
點(diǎn)擊閱讀：SparkStreaming實(shí)時(shí)任務(wù)處理的三種語義
在所有人都認(rèn)為Spark+SparkStreaming是大數(shù)據(jù)計(jì)算最佳實(shí)踐的時(shí)候，Apache沒有停止技術(shù)創(chuàng)新的腳步。雖然我沒有深挖，但是我猜想，是兩個(gè)流派對(duì)流式數(shù)據(jù)兩個(gè)不同的認(rèn)知，從而發(fā)展出兩套流式計(jì)算的體系。
與AMP實(shí)驗(yàn)室的"流是批的特例"不一樣，Apache基金會(huì)對(duì)于流式數(shù)據(jù)的認(rèn)知正好反過來，他們認(rèn)為"批是流的特例"。
如果AMP認(rèn)為光是波，那么Apache基金會(huì)則認(rèn)為光是粒子。兩種認(rèn)知，產(chǎn)生了同樣優(yōu)秀的兩個(gè)不同的產(chǎn)品。
Apache基金會(huì)2016年發(fā)布Flink1.0版以來，受到了市場極大的關(guān)注。比如阿里在Flink基礎(chǔ)上繼續(xù)優(yōu)化改造成了Blink。
基于"批是流的特例"的認(rèn)知，F(xiàn)link類同于Strom，數(shù)據(jù)來一條處理一條，真正實(shí)現(xiàn)了流式數(shù)據(jù)處理。
這種處理模式與Storm一樣，擁有極低的延遲，比SparkStreaming要高，但是比Spark要低。
Flink通過進(jìn)程內(nèi)部的各種優(yōu)化，降低數(shù)據(jù)傳輸頻次，提升傳輸速度，多個(gè)邏輯之間可以通過Chain機(jī)制，通過一個(gè)Task來處理多個(gè)算子。通過方法調(diào)用傳參的形式進(jìn)程數(shù)據(jù)傳輸，大大降低所需傳輸?shù)臄?shù)據(jù)。
另外，F(xiàn)link還創(chuàng)造了一種超級(jí)優(yōu)雅的流式數(shù)據(jù)快照方式Checkpoint：
Checkpoint機(jī)制的實(shí)現(xiàn)原理是在需要設(shè)置快照的時(shí)候，由JobManager發(fā)起Checkpoint，在Source前放置一個(gè)Barrier標(biāo)識(shí)。
就像超市隔斷兩個(gè)顧客采購商品的“歡迎光臨”隔檔一樣，把快照前后的數(shù)據(jù)隔開。“歡迎光臨”Barrier下游的數(shù)據(jù)，F(xiàn)link會(huì)照常執(zhí)行。當(dāng)所有下游數(shù)據(jù)執(zhí)行完畢之后，各部分會(huì)上報(bào)當(dāng)前狀態(tài)數(shù)據(jù)，遞交至Checkpoint Source State保存起來。一旦節(jié)點(diǎn)出問題，重啟任務(wù)，然后到Checkpoint Source State讀取任務(wù)元數(shù)據(jù)即可繼續(xù)進(jìn)行。
另外，F(xiàn)link和Spark不一樣，對(duì)于亂序數(shù)據(jù)也提出了非常優(yōu)雅的解決方案：Watermark。
Watermark就像是野外徒步小隊(duì)中的后隊(duì)領(lǐng)隊(duì)一樣，它決定了這個(gè)window的預(yù)期最后一個(gè)數(shù)據(jù)。這樣能最大程度保證一個(gè)Flink Window的數(shù)據(jù)不會(huì)因?yàn)榫W(wǎng)絡(luò)延遲等原因造成數(shù)據(jù)的丟失。
而且Flink還通過Checkpoint等一系列的設(shè)計(jì)，控制了Flink的數(shù)據(jù)嚴(yán)格消費(fèi)一次（EXACTLY_ONCE）的計(jì)算原則，確保數(shù)據(jù)不丟、不重復(fù)。這也是優(yōu)于Strom點(diǎn)之一。
Flink嚴(yán)格來說，應(yīng)該是流批一體，因?yàn)樗暮诵氖橇?，同時(shí)能做批處理。這種架構(gòu)被稱為Kappa架構(gòu)，與Spark+SparkStreaming的Lambda架構(gòu)對(duì)應(yīng)。
Spark Streaming 里的 DStream其實(shí)還是一個(gè)小的批，由定時(shí)器通知處理系統(tǒng)進(jìn)行處理。這樣的操作是用批的方式實(shí)現(xiàn)流式計(jì)算，但是會(huì)有不支持亂序、難以處理復(fù)雜流計(jì)算、背壓等各種問題。另外，Spark Streaming不能很好的支持exactly-once 語義（可以，但是會(huì)變慢），只能較好的支持 at-least-once 語義。
而Flink以數(shù)據(jù)流為核心認(rèn)知，將數(shù)據(jù)理解為最細(xì)顆粒度，從根本解決了流式數(shù)據(jù)計(jì)算的問題。它的各種窗口能靈活應(yīng)對(duì)各種流、批數(shù)據(jù)處理需求，滿足各種復(fù)雜的流式計(jì)算。
用Watermark解決亂序問題，用Checkpoint等各種設(shè)計(jì)達(dá)成exactly-once語義。一套工具，解決流、批數(shù)據(jù)處理的所有需求。這符合了廣大數(shù)據(jù)工作者追求功能強(qiáng)大、一套通用、使用友好的完美計(jì)算引擎想象。關(guān)鍵是Flink還非常簡單易用，所以Flink不火都天理難容??！
Flink擴(kuò)展閱讀：
點(diǎn)擊閱讀：Flink的Checkpoints機(jī)制詳解
點(diǎn)擊閱讀：Flink如何巧用WaterMark機(jī)制解決亂序問題
Flink是終結(jié)者嗎？我想不會(huì)的。縱觀大數(shù)據(jù)計(jì)算引擎的發(fā)展歷史，我們可以看到：
Hadoop的MapRedce開創(chuàng)了超大規(guī)模數(shù)據(jù)集合處理的先河，Strom開創(chuàng)了分布式流式數(shù)據(jù)計(jì)算引擎，可以為奉為大數(shù)據(jù)計(jì)算引擎鼻祖。
Spark充分利用內(nèi)存，將超大規(guī)模數(shù)據(jù)集合處理速度提升了百倍；SparkStreaming則用微批理念處理流式數(shù)據(jù)，進(jìn)一步解決Storm可能重復(fù)消費(fèi)的弊病，同時(shí)降低延遲，提升效率，可以奉為第二代大數(shù)據(jù)計(jì)算引擎；
Flink創(chuàng)新性的引入Checkpoint機(jī)制、Watermark機(jī)制、各種靈活的窗口，同時(shí)滿足流、批數(shù)據(jù)的超高吞吐、低延遲、靈活快速計(jì)算的各種需求，可以奉為第三代大數(shù)據(jù)計(jì)算引擎。
但是Flink仍然尚在不斷發(fā)展，尚有更多有待優(yōu)化和解決的點(diǎn)。無比期待Flink能越來越好。同樣，我無比期望有更強(qiáng)的牛人，能創(chuàng)造出更加優(yōu)秀的計(jì)算引擎！也希望朋友圈也能出現(xiàn)這樣的牛人，我好頂禮膜拜
有人問，老彭，你這每天都這么寫，怎么能堅(jiān)持下來??？其實(shí)這個(gè)問題就很有意思，這些朋友的潛臺(tái)詞是每天花4、5個(gè)小時(shí)一屁股坐下來寫東西，還要畫畫，這樣太痛苦了。其實(shí)不然！我在學(xué)習(xí)、整理資料的過程，其實(shí)就是在與那一個(gè)個(gè)聰明的大腦隔空神交，欣賞這些奇思妙想，用各種聞所未聞的腦洞來解決各種看似不可解的難題，這得多帶勁??？雖然我的老腰都快斷了
另外，本文只是綜述，不是選型依據(jù)。一個(gè)合格的架構(gòu)師應(yīng)該明白，最好的架構(gòu)是最適合當(dāng)前業(yè)務(wù)場景，且滿足現(xiàn)有條件的，而不是最前沿的技術(shù)。
如果我沒說清楚，可以在后臺(tái)留言，我們一起學(xué)習(xí)，共同進(jìn)步。感謝！
配合以下文章享受更佳
干貨 | 一口氣說穿中臺(tái)-給你架構(gòu)師的視角
全解 | 一口氣說穿數(shù)據(jù)中臺(tái)-給你架構(gòu)師的視角
我需要你的點(diǎn)贊，愛你喲
本文為作者獨(dú)立觀點(diǎn)，不代表鳥哥筆記立場，未經(jīng)允許不得轉(zhuǎn)載。
《鳥哥筆記版權(quán)及免責(zé)申明》 如對(duì)文章、圖片、字體等版權(quán)有疑問，請點(diǎn)擊 反饋舉報(bào)
我們致力于提供一個(gè)高質(zhì)量內(nèi)容的交流平臺(tái)。為落實(shí)國家互聯(lián)網(wǎng)信息辦公室“依法管網(wǎng)、依法辦網(wǎng)、依法上網(wǎng)”的要求，為完善跟帖評(píng)論自律管理，為了保護(hù)用戶創(chuàng)造的內(nèi)容、維護(hù)開放、真實(shí)、專業(yè)的平臺(tái)氛圍，我們團(tuán)隊(duì)將依據(jù)本公約中的條款對(duì)注冊用戶和發(fā)布在本平臺(tái)的內(nèi)容進(jìn)行管理。平臺(tái)鼓勵(lì)用戶創(chuàng)作、發(fā)布優(yōu)質(zhì)內(nèi)容，同時(shí)也將采取必要措施管理違法、侵權(quán)或有其他不良影響的網(wǎng)絡(luò)信息。
一、根據(jù)《網(wǎng)絡(luò)信息內(nèi)容生態(tài)治理規(guī)定》《中華人民共和國未成年人保護(hù)法》等法律法規(guī)，對(duì)以下違法、不良信息或存在危害的行為進(jìn)行處理。
1. 違反法律法規(guī)的信息，主要表現(xiàn)為：
1)反對(duì)憲法所確定的基本原則；
2)危害國家安全，泄露國家秘密，顛覆國家政權(quán)，破壞國家統(tǒng)一，損害國家榮譽(yù)和利益；
3)侮辱、濫用英烈形象，歪曲、丑化、褻瀆、否定英雄烈士事跡和精神，以侮辱、誹謗或者其他方式侵害英雄烈士的姓名、肖像、名譽(yù)、榮譽(yù)；
4)宣揚(yáng)恐怖主義、極端主義或者煽動(dòng)實(shí)施恐怖活動(dòng)、極端主義活動(dòng)；
5)煽動(dòng)民族仇恨、民族歧視，破壞民族團(tuán)結(jié)；
6)破壞國家宗教政策，宣揚(yáng)邪教和封建迷信；
7)散布謠言，擾亂社會(huì)秩序，破壞社會(huì)穩(wěn)定；
8)宣揚(yáng)淫穢、色情、賭博、暴力、兇殺、恐怖或者教唆犯罪；
9)煽動(dòng)非法集會(huì)、結(jié)社、游行、示威、聚眾擾亂社會(huì)秩序；
10)侮辱或者誹謗他人，侵害他人名譽(yù)、隱私和其他合法權(quán)益；
11)通過網(wǎng)絡(luò)以文字、圖片、音視頻等形式，對(duì)未成年人實(shí)施侮辱、誹謗、威脅或者惡意損害未成年人形象進(jìn)行網(wǎng)絡(luò)欺凌的；
12)危害未成年人身心健康的；
13)含有法律、行政法規(guī)禁止的其他內(nèi)容；
2. 不友善：不尊重用戶及其所貢獻(xiàn)內(nèi)容的信息或行為。主要表現(xiàn)為：
1)輕蔑：貶低、輕視他人及其勞動(dòng)成果；
2)誹謗：捏造、散布虛假事實(shí)，損害他人名譽(yù)；
3)嘲諷：以比喻、夸張、侮辱性的手法對(duì)他人或其行為進(jìn)行揭露或描述，以此來激怒他人；
4)挑釁：以不友好的方式激怒他人，意圖使對(duì)方對(duì)自己的言論作出回應(yīng)，蓄意制造事端；
5)羞辱：貶低他人的能力、行為、生理或身份特征，讓對(duì)方難堪；
6)謾罵：以不文明的語言對(duì)他人進(jìn)行負(fù)面評(píng)價(jià)；
7)歧視：煽動(dòng)人群歧視、地域歧視等，針對(duì)他人的民族、種族、宗教、性取向、性別、年齡、地域、生理特征等身份或者歸類的攻擊；
8)威脅：許諾以不良的后果來迫使他人服從自己的意志；
3. 發(fā)布垃圾廣告信息：以推廣曝光為目的，發(fā)布影響用戶體驗(yàn)、擾亂本網(wǎng)站秩序的內(nèi)容，或進(jìn)行相關(guān)行為。主要表現(xiàn)為：
1)多次發(fā)布包含售賣產(chǎn)品、提供服務(wù)、宣傳推廣內(nèi)容的垃圾廣告。包括但不限于以下幾種形式：
2)單個(gè)帳號(hào)多次發(fā)布包含垃圾廣告的內(nèi)容；
3)多個(gè)廣告帳號(hào)互相配合發(fā)布、傳播包含垃圾廣告的內(nèi)容；
4)多次發(fā)布包含欺騙性外鏈的內(nèi)容，如未注明的淘寶客鏈接、跳轉(zhuǎn)網(wǎng)站等，誘騙用戶點(diǎn)擊鏈接
5)發(fā)布大量包含推廣鏈接、產(chǎn)品、品牌等內(nèi)容獲取搜索引擎中的不正當(dāng)曝光；
6)購買或出售帳號(hào)之間虛假地互動(dòng)，發(fā)布干擾網(wǎng)站秩序的推廣內(nèi)容及相關(guān)交易。
7)發(fā)布包含欺騙性的惡意營銷內(nèi)容，如通過偽造經(jīng)歷、冒充他人等方式進(jìn)行惡意營銷；
8)使用特殊符號(hào)、圖片等方式規(guī)避垃圾廣告內(nèi)容審核的廣告內(nèi)容。
4. 色情低俗信息，主要表現(xiàn)為：
1)包含自己或他人性經(jīng)驗(yàn)的細(xì)節(jié)描述或露骨的感受描述；
2)涉及色情段子、兩性笑話的低俗內(nèi)容；
3)配圖、頭圖中包含庸俗或挑逗性圖片的內(nèi)容；
4)帶有性暗示、性挑逗等易使人產(chǎn)生性聯(lián)想；
5)展現(xiàn)血腥、驚悚、殘忍等致人身心不適；
6)炒作緋聞、丑聞、劣跡等；
7)宣揚(yáng)低俗、庸俗、媚俗內(nèi)容。
5. 不實(shí)信息，主要表現(xiàn)為：
1)可能存在事實(shí)性錯(cuò)誤或者造謠等內(nèi)容；
2)存在事實(shí)夸大、偽造虛假經(jīng)歷等誤導(dǎo)他人的內(nèi)容；
3)偽造身份、冒充他人，通過頭像、用戶名等個(gè)人信息暗示自己具有特定身份，或與特定機(jī)構(gòu)或個(gè)人存在關(guān)聯(lián)。
6. 傳播封建迷信，主要表現(xiàn)為：
1)找人算命、測字、占卜、解夢、化解厄運(yùn)、使用迷信方式治?。?br /> 2)求推薦算命看相大師；
3)針對(duì)具體風(fēng)水等問題進(jìn)行求助或咨詢；
4)問自己或他人的八字、六爻、星盤、手相、面相、五行缺失，包括通過占卜方法問婚姻、前程、運(yùn)勢，東西寵物丟了能不能找回、取名改名等；
7. 文章標(biāo)題黨，主要表現(xiàn)為：
1)以各種夸張、獵奇、不合常理的表現(xiàn)手法等行為來誘導(dǎo)用戶；
2)內(nèi)容與標(biāo)題之間存在嚴(yán)重不實(shí)或者原意扭曲；
3)使用夸張標(biāo)題，內(nèi)容與標(biāo)題嚴(yán)重不符的。
8.「飯圈」亂象行為，主要表現(xiàn)為：
1)誘導(dǎo)未成年人應(yīng)援集資、高額消費(fèi)、投票打榜
2)粉絲互撕謾罵、拉踩引戰(zhàn)、造謠攻擊、人肉搜索、侵犯隱私
3)鼓動(dòng)「飯圈」粉絲攀比炫富、奢靡享樂等行為
4)以號(hào)召粉絲、雇用網(wǎng)絡(luò)水軍、「養(yǎng)號(hào)」形式刷量控評(píng)等行為
5)通過「蹭熱點(diǎn)」、制造話題等形式干擾輿論，影響傳播秩序
9. 其他危害行為或內(nèi)容，主要表現(xiàn)為：
1)可能引發(fā)未成年人模仿不安全行為和違反社會(huì)公德行為、誘導(dǎo)未成年人不良嗜好影響未成年人身心健康的；
2)不當(dāng)評(píng)述自然災(zāi)害、重大事故等災(zāi)難的；
3)美化、粉飾侵略戰(zhàn)爭行為的；
4)法律、行政法規(guī)禁止，或可能對(duì)網(wǎng)絡(luò)生態(tài)造成不良影響的其他內(nèi)容。
二、違規(guī)處罰
本網(wǎng)站通過主動(dòng)發(fā)現(xiàn)和接受用戶舉報(bào)兩種方式收集違規(guī)行為信息。所有有意的降低內(nèi)容質(zhì)量、傷害平臺(tái)氛圍及欺凌未成年人或危害未成年人身心健康的行為都是不能容忍的。
當(dāng)一個(gè)用戶發(fā)布違規(guī)內(nèi)容時(shí)，本網(wǎng)站將依據(jù)相關(guān)用戶違規(guī)情節(jié)嚴(yán)重程度，對(duì)帳號(hào)進(jìn)行禁言 1 天、7 天、15 天直至永久禁言或封停賬號(hào)的處罰。當(dāng)涉及欺凌未成年人、危害未成年人身心健康、通過作弊手段注冊、使用帳號(hào)，或者濫用多個(gè)帳號(hào)發(fā)布違規(guī)內(nèi)容時(shí)，本網(wǎng)站將加重處罰。
三、申訴
隨著平臺(tái)管理經(jīng)驗(yàn)的不斷豐富，本網(wǎng)站出于維護(hù)本網(wǎng)站氛圍和秩序的目的，將不斷完善本公約。
如果本網(wǎng)站用戶對(duì)本網(wǎng)站基于本公約規(guī)定做出的處理有異議，可以通過「建議反饋」功能向本網(wǎng)站進(jìn)行反饋。
(規(guī)則的最終解釋權(quán)歸屬本網(wǎng)站所有)