整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
責(zé)聲明：本文旨在傳遞更多市場信息，不構(gòu)成任何投資建議。文章僅代表作者觀點，不代表MarsBit官方立場。
小編：記得關(guān)注哦
來源：MarsBit
11 月 13 日，Elon Musk為 Twitter 進行了 1000 多次RPC來呈現(xiàn)用戶的主頁時間線而道歉。乍一看，如此大量的 RPC 似乎很荒謬。如今，Twitter 每月為 2.6 億活躍用戶提供服務(wù)，并且可以近乎實時地提供服務(wù)。為了解決亞秒級延遲的大規(guī)模采用問題，Twitter 率先推出了許多解決方案，包括 Apache Storm、Heron、DistributedLog和Aurora。他是Scala 的主要貢獻者，包括finagle RPC 框架，以及l(fā)ambda 架構(gòu)、Snowflake ID和Segcache等創(chuàng)新。那么，為什么像 Twitter 這樣的創(chuàng)新型全球化公司需要如此多的調(diào)用來獲取用戶的時間線數(shù)據(jù)？
Twitter所面臨的問題讓我們想起了當(dāng)前Web3中不斷增長的煩惱：開發(fā)者常常被迫一個接一個地連續(xù)調(diào)用許多 API 來獲取組裝業(yè)務(wù)邏輯的數(shù)據(jù)。這會導(dǎo)致性能不可靠且不可預(yù)測，即使對于最簡單的用例也是如此，例如獲取用戶的交易歷史記錄。就增長而言，前十大公鏈的交易量在兩年內(nèi)翻了 100 倍。在圖 1 中，我們展示了每秒推文數(shù)量（2006-2013，藍色）和每秒 Web3 交易數(shù)量（2017-2022，紅色，排除非用戶交易）之間的比較。如果 Web3 繼續(xù)沿著圖中描繪的軌跡發(fā)展，那么當(dāng)今大多數(shù) Web3 數(shù)據(jù)基礎(chǔ)設(shè)施解決方案將無法應(yīng)對增長。
圖 1：推文與 Web3排名前10的鏈早期寫流量 QPS 對比。
在這篇博文中，我們將重點介紹Web3可以從Twitter的擴展解決方案中學(xué)到什么。具體來說，我們討論以下內(nèi)容:
?我們概述了 Twitter 的時間線基礎(chǔ)設(shè)施之旅，認為他們當(dāng)前的架構(gòu)確實對特定用例有意義，并得出結(jié)論，一些批評可能是錯誤的，例如 Elon Musk最近的推文為渲染主頁時間線的大量 RPC 道歉。
?我們深入研究 Twitter 和 Web3 之間的技術(shù)相似性，并探索前者的解決方案如何使后者的解決方案受益。
?我們分析了當(dāng)前的 Web3 增長趨勢，以及缺乏現(xiàn)有的高性能數(shù)據(jù)基礎(chǔ)設(shè)施解決方案，并得出結(jié)論，如果我們想要支持實時 Web3 數(shù)據(jù)訪問，則需要進行重大升級，以及ZettaBlock解決方案如何幫助開發(fā)人員減少70%的開發(fā)時間，并將性能提高 10 倍，演示可以在這里找到 [網(wǎng)站，視頻]
一開始，Twitter使用Vanilla MySQL。這很快成為了一個問題，因為在最初的幾年里，推文的數(shù)量每年增長10倍。從2007年到2012年，Twitter的月活躍用戶從幾千人增長到超過1.38億。已知的水平和垂直切分的知識無法為Twitter處理高流量的性能，尤其是在渲染主頁時間線方面。
時間線是 Twitter 的主要平臺功能之一。一般來說，Twitter的時間線主要有兩個操作，具體如下:
1.寫入路徑：該路徑用于用戶發(fā)布推文。2012年，Twitter平均每秒處理4.6萬個寫入請求，在高峰時段處理1.2萬個RPS。
2.讀取路徑：此路徑用于用戶請求他們的時間線。2012 年，Twitter 每秒處理大約 30 萬次讀取請求。
為了更好地理解 Twitter 如何呈現(xiàn)時間線，讓我們更深入地研究呈現(xiàn)流程，如圖 2 所示。當(dāng) Twitter 用戶今天發(fā)布一條推文時，Twitter 首先將其寫入Manhattan，一個分布式鍵值數(shù)據(jù)庫，用于存儲用戶推文、直接消息、帳戶詳細信息等。該推文在時間線緩存中向該用戶的所有關(guān)注者展開。雖然這將寫入放大從每秒 4.6k 請求增加到每秒 345k 請求，但它也大大降低了用戶的讀取延遲。因此，時間線渲染不是在關(guān)注者和推文之間做一個連接表，而是從緩存中的單個表中獲取推文。這些操作通常在不到 5 秒的時間內(nèi)完成。通過分布正在寫入的數(shù)據(jù)，系統(tǒng)可以通過刪除表連接來避免過度增長。因此，讀取延遲被改進到幾百毫秒。
圖 2：Twitter 的時間線渲染流程。請注意，時間線中的每條推文都需要至少一個 RPC。
前面提到的渲染流程對于絕大多數(shù)用戶來說可能已經(jīng)足夠了（在大多數(shù)情況下寫入放大值
圖 3：左側(cè)描繪了 Twitter 用戶混合時間線的抽象說明，右側(cè)描繪了相應(yīng)的讀取 SQL。
既然我們已經(jīng)描述了提供實時推文時間線背后的復(fù)雜性，那么為什么單個時間線渲染需要許多 RPC 就很清楚了。例如，對于只有 100 條推文的時間線，RPC 調(diào)用很容易超過 1000 次，因為僅僅獲取一條推文就需要多次RPC調(diào)用。該解決方案乍一看可能并不直觀，但它是一種經(jīng)過深思熟慮的權(quán)衡，旨在為最終用戶提供優(yōu)化且可預(yù)測的讀取性能。
Twitter 實現(xiàn)的最終結(jié)果非常積極：99%的延遲只有幾百毫秒左右。在過去的 10 年里，這種基礎(chǔ)架構(gòu)已經(jīng)被證明是可靠的，可以在沒有重大變化的情況下處理Twitter流量的高速增長。
請注意，我們忽略了Twitter時間線的其他方面，包括評分、排名等。有關(guān)這方面的更多詳細信息，請參閱本文末尾列出的參考資料。
圖 4：Twitter 和 Web3 數(shù)據(jù)的相似之處
Twitter 和 Web3 生態(tài)系統(tǒng)有很多相似之處：
1.Web3是一個社交圖譜，推文類似于交易，回復(fù)類似于日志。圖4描述了這一點，其中比較了順序時間線渲染和順序區(qū)塊鏈的塊。
2.Web3 協(xié)議和 Twitter 存在超級中心效應(yīng)。最受歡迎的NFT平臺的交易量是第10個平臺的1000倍。
3.Web3 和 twitter 都是開放平臺，對所有用戶可見，并允許某些 API 訪問。
如果我們放大一點，Twitter 和 Web3 之間的數(shù)據(jù)訪問模式有更多相似之處：
1.讀取量大，但每條記錄很小。在 EVM 鏈上，日志和交易的平均大小只有幾KB。
2.最新數(shù)據(jù)將被更頻繁地查看，其中大部分查看來自發(fā)布后的前幾個小時。
3.數(shù)據(jù)在短時間是不可變的。鏈上數(shù)據(jù)可以通過reorg恢復(fù)最新的區(qū)塊。同樣，現(xiàn)在用戶可以在發(fā)布后的一段時間內(nèi)編輯推文。
與 2020 年初相比，前 10 大鏈的交易量已經(jīng)增長了近 100 倍。Web3 數(shù)據(jù)基礎(chǔ)設(shè)施的現(xiàn)狀類似于 2008 年前后的 Twitter 早期，當(dāng)時大部分流量依賴于來自不同提供商的水平分片數(shù)據(jù)庫。因此，隨著 Web3 的持續(xù)增長，現(xiàn)有的 Web3 數(shù)據(jù)基礎(chǔ)設(shè)施將很難提供對數(shù)據(jù)的高性能訪問。
來自 Twitter 的扇出服務(wù)是將相關(guān)數(shù)據(jù)同時放在同一位置（如內(nèi)存）。這樣，當(dāng)一個請求到來時，系統(tǒng)可以很容易地在一個地方找到相關(guān)數(shù)據(jù)，這導(dǎo)致數(shù)據(jù)已經(jīng)被預(yù)處理并可以使用。這使得系統(tǒng)具有可擴展性，和可預(yù)測的性能。
遵循當(dāng)前現(xiàn)狀的 Web3 應(yīng)用程序缺少一個重要的組件來有效地聚合相關(guān)數(shù)據(jù)。具體來說，開發(fā)者必須一個一個地調(diào)用API來獲取數(shù)據(jù)。即使對于最簡單的用例，例如獲取用戶的交易歷史記錄（如圖 5 所示），這也會導(dǎo)致性能不可靠且不可預(yù)測。
圖 5：當(dāng)前的 Web3 應(yīng)用程序需要如何連續(xù)調(diào)用許多不同的 API，即使是簡單的事務(wù)聚合。
由于所有 Web3 數(shù)據(jù)都是公開可用的，ZettaBlock 構(gòu)建了最先進的數(shù)據(jù)基礎(chǔ)設(shè)施來處理所有 Web3 開發(fā)人員的扇出部分。應(yīng)用程序開發(fā)人員只需通過一個 API 指定他們想要查詢哪些相關(guān)數(shù)據(jù)，然后讓 ZettaBlock 聚合所有相關(guān)數(shù)據(jù)。如圖 6 所示。通過使用 ZettaBlock，開發(fā)時間和 API 延遲分別減少了 70% 和 90%。在https://demo.zettablock.dev/查看我們的演示。更多的技術(shù)細節(jié)將在未來分享。
圖 6：與圖 5 相比，ZettaBlock 將多個 Web3 數(shù)據(jù)集抽象為一個簡單、用戶友好且高效的API。
在這篇博文中，我們剖析了 Twitter 的架構(gòu)，并將其數(shù)據(jù)模型與 Web3 進行了比較，發(fā)現(xiàn)了許多相似之處。如果我們能得到一個信息，那就是許多現(xiàn)有的 Web3 數(shù)據(jù)基礎(chǔ)設(shè)施解決方案，就像早期的 Twitter 一樣，將無法跟上即將到來的數(shù)據(jù)需求。
這就是我們構(gòu)建 ZettaBlock 的原因。ZettaBlock 是一個全棧式 Web3 數(shù)據(jù)基礎(chǔ)設(shè)施平臺，可提供實時、可靠的 API 和分析，在幾分鐘內(nèi)為您的應(yīng)用程序提供支持。前面提到的扇出過程（將相關(guān)數(shù)據(jù)同時放在同一個地方），這只是 ZettaBlock 上開發(fā)人員和企業(yè)可用的眾多功能之一。我們受到領(lǐng)先的web3公司的信任，如Polygon, Crypto.com, Circle等。我們的愿景是成為web3數(shù)據(jù)基礎(chǔ)設(shè)施的首選平臺。
請查看我們的演示/視頻了解詳細信息。
鳴謝
我想借此機會向所有在這篇文章中幫助過我的人表示衷心的感謝。特別感謝Kevin Ros、Chi Zhang、Maria Adamjee、Raphael Serrano、Zhenzhong Xu、Paul Tluczek、Tianzhou Chen、Hemanth Soni、Nitish Sharma、Ryan Kim、Alex Xu、Vivek Gopalan、Nazih Kalo、Nirmal Krishnan、Timothy Chen、Min Hao、Bo Yang
1.Timelines at Scale:
https://www.infoq.com/presentations/Twitter-Timeline-Scalability/
2.How Twitter uses redis to scale 105TB RAM:
http://highscalability.com/blog/2014/9/8/how-twitter-uses-redis-to-scale-105tb-ram-39mm-qps-10000-ins.html
3.What Database does Twitter use?
https://scaleyourapp.com/what-database-does-twitter-use-a-deep-dive/
4.Twitter Data Storage and Processing:
https://ankush-chavan.medium.com/twitter-data-storage-and-processing-dd13fd0fdb30#:~:text=That%20equals%20to%20the%2084,time%20the%20request%20is%20made
責(zé)任編輯：Kate
檢察長大人 ins 傳送門
幾年前我就用 python 寫過一版 instagram 爬蟲，當(dāng)時能做到下載我收藏的圖片到本機。后來某天不能用了，調(diào)試后發(fā)現(xiàn)是 instagram 修改了登錄接口的數(shù)據(jù)格式，導(dǎo)致爬蟲無法登錄，也就不能下載圖片了
最近我在 github 上找了幾個 instagram 爬蟲的代碼，很幸運的在 instaloader 里找到了登錄 instagram 的正確數(shù)據(jù)格式，基于在個人博客上展示的需求，重新開發(fā)了爬蟲
注意：instagram 會監(jiān)控用戶的行為，如果你的兩次訪問之間間隔太快，或者調(diào)用接口次數(shù)太多，會凍結(jié)你的訪問，此時接口會返回 429 狀態(tài)碼，大概要等 24 小時才會解凍
我的解決方案是在兩次訪問之間隨機休眠 2——4 秒，而且每 15 次訪問額外休眠 60——90 秒，這樣觸發(fā)凍結(jié)的概率比較小
爬蟲代碼我近期會整理脫敏后開源到 github，請關(guān)注
NataLee：360 度無死角，完美的性感女神
makenzie_raine: 青春洋溢，美少女
theanastasiah: hotter than your ex better than your next, 很符合國人審美的俄羅斯模特
nicolaca_: YOU NEVER LOSE. EITHER YOU WIN or YOU LEARN. 來自德國的模特
realbarbarapalvin: 維密超模
所謂超文本，有2層含義：
標(biāo)題標(biāo)簽 <hx></hx>
段落標(biāo)簽 <p></p>
水平線標(biāo)簽 <hr />
換行標(biāo)簽 <br/>
無語義標(biāo)簽 <div></div> 和 <span></span> 注:這兩個標(biāo)簽在后期經(jīng)常使用文本格式化標(biāo)簽
<b></b>和<strong></strong> 文字加粗
<i></i>和<em></em> 斜體
<s></s>和<del></del> 加刪除線
<u></u>和<ins></ins> 加下劃線圖片標(biāo)簽
<img src="圖像URL" /> src 圖像路徑 圖像標(biāo)簽 <img src="圖像URL" /> 該語法中src屬性用于指定圖像文件的路徑和文件名，他是img標(biāo)簽的必需屬性。
屬性:
alt 文本,圖像不顯示時顯示文字<img src="" alt="">
title 文本,鼠標(biāo)懸停時顯示內(nèi)容<img src="cz.jpg" title="文本" />
width 圖像寬度<img src="cz.jpg" width="300" height="300" />
height 圖像高度<img src="cz.jpg" width="300" height="300" />
border 設(shè)置圖像邊框?qū)挾?lt;img src="cz.jpg" border="3" />
鏈接標(biāo)簽
<a href="#" target="目標(biāo)窗口的彈出方式">文本或圖像</a>屬性：
href (鏈接地址)必須寫 | 用于指定鏈接目標(biāo)的url地址，（必須屬性）當(dāng)為標(biāo)簽應(yīng)用href屬性時，它就具有了超鏈接的功能 | 1. 外部鏈接 需要添加 http:// www.baidu.com | ||
target (默認當(dāng)前窗口打開,可新建窗口打開) | 用于指定鏈接頁面的打開方式，其取值有self和blank兩種，其中_self為默認值，__blank為在新窗口中打開方式。 |
錨點標(biāo)簽
id="" | 錨點定位 | 通過創(chuàng)建錨點鏈接，用戶能夠快速定位到目標(biāo)內(nèi)容。 | <h3 id="two">第2集</h3> | 使用相應(yīng)的id名標(biāo)注跳轉(zhuǎn)目標(biāo)的位置。 (找目標(biāo)) |
base標(biāo)簽
<base target="_blank" /> | base 可以設(shè)置整體鏈接的打開狀態(tài) | base 寫到 <head> </head> 之間 |
預(yù)格式化標(biāo)簽
<pre>文本</pre> | 標(biāo)簽可定義預(yù)格式化的文本。 | 所謂的預(yù)格式化文本就是 ，按照我們預(yù)先寫好的文字格式來顯示頁面， 保留空格和換行等。 |
表格標(biāo)簽
<table> 定義表格標(biāo)簽 | border | 設(shè)置表格邊框(默認border="0"無邊框) | <table> |
cellspacing | 設(shè)置單元格與單元格之間的空白間距 (默認2像素) | ||
cellpadding | 設(shè)置單元格內(nèi)容與單元格邊框之間的空白間距 (默認1像素) | ||
width | 設(shè)置表格的寬度 | ||
height | 設(shè)置表格的高度 | ||
align | 設(shè)置表格在網(wǎng)頁中的水平對齊方式 (三個屬性:left左 center中 right右 ) | align="center" align="right" | |
caption | caption 元素定義表格標(biāo)題，通常這個標(biāo)題會被居中且顯示于表格之上。 | <caption>個人信息表</caption> | |
rowspan="合并單元格的個數(shù)" | 跨行合并 | 合并的順序我們按照 先上 后下 先左 后右 的順序 | |
colspan="合并單元格的個數(shù)" | 跨列合并 | <td colspan="3"> </td> | |
<caption></caption> | 表格標(biāo)題標(biāo)簽 | ||
<tr></tr><td></td> | 標(biāo)簽，他就像一個容器，可以容納所有的元素 | <tr><td></td></tr> | |
<th><td> | 一般表頭單元格位于表格的第一行或第一列，并且文本加粗居中 | <th><td></td></th> | |
<thead> 于定義表格的頭部。用來放標(biāo)題之類的東西。<thead> 內(nèi)部必須擁有 <tr> 標(biāo)簽！ | 以上標(biāo)簽都是放到table標(biāo)簽中。 | 更好的給表格劃分結(jié)構(gòu) | |
<tbody> 用于定義表格的主體。放數(shù)據(jù)本體 。 | 以上標(biāo)簽都是放到table標(biāo)簽中。 | ||
<tfoot>放表格的腳注之類。 | 以上標(biāo)簽都是放到table標(biāo)簽中。 |
列表標(biāo)簽
列表(ul里面只能包含li ,li里面可以包含標(biāo)簽) | <ul><li></li></ul> | 無序列表 | 1. <ul></ul>中只能嵌套<li></li>，直接在<ul></ul>標(biāo)簽中輸入其他標(biāo)簽或者文字的做法是不被允許的。 | 里面只能包含li 沒有順序，我們以后布局中最常用的列表 | ||
<ol><li></li></ol> | 有序列表 | 所有特性基本與ul 一致。 但是實際中比 無序列表 用的少很多。 | 里面只能包含li 有順序， 使用情況較少 | |||
<dl> | 自定義列表 | 里面有2個兄弟， dt 和 dd |
input控件
<input type="屬性值" value="你好"> | text | 單行文本輸入框 | |
password | 密碼輸入框 | ||
radio | 單選按鈕 | ||
checkbox | 復(fù)選按鈕 | ||
button | 普通按鈕 | ||
submit | 提交按鈕 | ||
reset | 重置按鈕 | ||
image | 圖像形式的提交按鈕 | ||
file | 文本域 | ||
name | 由用戶自定義 | 控件的名稱 | 用戶名:<input type="text" name=“username” /> |
value | 由用戶自定義 | input控件中的默認問本值 | 用戶名:<input type="text" name="username" value="請輸入用戶名"> |
size | 正整數(shù) | input控件在頁面中的顯示寬度 | |
checked 默認被選中 | checked | 定義選擇控件默認被選中的項 | <input type="radio" name="sex" value="女" />女 |
maxlength | 正整數(shù) | 控件允許輸入的最多字符數(shù) |
<label> </label>
<label> 用戶名： <input type="radio" name="usename" value="請輸入用戶名"> </label> | 第一種用法就是用label直接包括input表單。 | 當(dāng)我們鼠標(biāo)點擊 label標(biāo)簽里面的文字時， 光標(biāo)會定位到指定的表單里面 | |
<label for="sex">男</label> | 第二種用法 for 屬性規(guī)定 label 與哪個表單元素綁定。 | 當(dāng)我們鼠標(biāo)點擊 label標(biāo)簽里面的文字時， 光標(biāo)會定位到指定的表單里面 |
文本域
<textarea >文本內(nèi)容</textarea> | 通過textarea控件可以輕松地創(chuàng)建多行文本輸入框. | cols="每行中的字符數(shù)" rows="顯示的行數(shù)" 我們實際開發(fā)不用 | <textarea > 文本內(nèi)容</textarea> |
select下拉列表
<select> | 在option 中定義selected=" selected "時，當(dāng)前項即為默認選中項。 |
form表單域
<form action="url地址" method="提交方式" name="表單名稱"> | action 屬性值:url地址 | 用于指定接收并處理表單數(shù)據(jù)的服務(wù)器程序的url地址。 |
method 屬性值:get/post | 用于設(shè)置表單數(shù)據(jù)的提交方式，其取值為get或post。 | |
name 屬性值:名稱 | 用于指定表單的名稱，以區(qū)分同一個頁面中的多個表單。 |
以上標(biāo)簽基本包含了前端開發(fā)所需常用標(biāo)簽.來自本人,黑馬程序員.傳智播客學(xué)習(xí)筆記.
以下是個人筆記整理,需要請關(guān)注私信我.
希望本人筆記能對各位有所幫助.
前端不難,難的在于東西多和雜.每天努力學(xué)習(xí)一點點,不放棄.
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
