rune是Go語言中一種特殊的數(shù)據(jù)類型,它是int32的別名,幾乎在所有方面等同于int32,用于區(qū)分字符值和整數(shù)值,官方解釋如下:
創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設(shè)計、做網(wǎng)站、成都外貿(mào)網(wǎng)站建設(shè)公司、網(wǎng)頁設(shè)計、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)石屏,10余年網(wǎng)站建設(shè)經(jīng)驗,價格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220
下面我們通過一個例子來看一下:
我們猜測一下結(jié)果,hello5 個字符+1 個空格+3 個漢子,算起來應(yīng)該是 9 個,長度為 9 才對,但是我們執(zhí)行一下,
結(jié)果打印是 15,這是為什么呢?
所以計算出的長度就等于 5+1+3*3=15
如果我們需要計算出字符串的長度,而不是底層字節(jié)的個數(shù),那么可以使用下面的方法:
運行結(jié)果如下:
在 rune 定義上方還有一個,byte = uint8
在Malwarebytes 我們經(jīng)歷了顯著的增長,自從我一年前加入了硅谷的公司,一個主要的職責(zé)成了設(shè)計架構(gòu)和開發(fā)一些系統(tǒng)來支持一個快速增長的信息安全公司和所有需要的設(shè)施來支持一個每天百萬用戶使用的產(chǎn)品。我在反病毒和反惡意軟件行業(yè)的不同公司工作了12年,從而我知道由于我們每天處理大量的數(shù)據(jù),這些系統(tǒng)是多么復(fù)雜。
有趣的是,在過去的大約9年間,我參與的所有的web后端的開發(fā)通常是通過Ruby on Rails技術(shù)實現(xiàn)的。不要錯怪我。我喜歡Ruby on Rails,并且我相信它是個令人驚訝的環(huán)境。但是一段時間后,你會開始以ruby的方式開始思考和設(shè)計系統(tǒng),你會忘記,如果你可以利用多線程、并行、快速執(zhí)行和小內(nèi)存開銷,軟件架構(gòu)本來應(yīng)該是多么高效和簡單。很多年期間,我是一個c/c++、Delphi和c#開發(fā)者,我剛開始意識到使用正確的工具可以把復(fù)雜的事情變得簡單些。
作為首席架構(gòu)師,我不會很關(guān)心在互聯(lián)網(wǎng)上的語言和框架戰(zhàn)爭。我相信效率、生產(chǎn)力。代碼可維護性主要依賴于你如何把解決方案設(shè)計得很簡單。
問題
當(dāng)工作在我們的匿名遙測和分析系統(tǒng)中,我們的目標(biāo)是可以處理來自于百萬級別的終端的大量的POST請求。web處理服務(wù)可以接收包含了很多payload的集合的JSON數(shù)據(jù),這些數(shù)據(jù)需要寫入Amazon S3中。接下來,map-reduce系統(tǒng)可以操作這些數(shù)據(jù)。
按照習(xí)慣,我們會調(diào)研服務(wù)層級架構(gòu),涉及的軟件如下:
Sidekiq
Resque
DelayedJob
Elasticbeanstalk Worker Tier
RabbitMQ
and so on…
搭建了2個不同的集群,一個提供web前端,另外一個提供后端處理,這樣我們可以橫向擴展后端服務(wù)的數(shù)量。
但是,從剛開始,在 討論階段我們的團隊就知道我們應(yīng)該使用Go,因為我們看到這會潛在性地成為一個非常龐大( large traffic)的系統(tǒng)。我已經(jīng)使用了Go語言大約2年時間,我們開發(fā)了幾個系統(tǒng),但是很少會達到這樣的負載(amount of load)。
我們開始創(chuàng)建一些結(jié)構(gòu),定義從POST調(diào)用得到的web請求負載,還有一個上傳到S3 budket的函數(shù)。
type PayloadCollection struct {
WindowsVersion string `json:"version"`
Token string `json:"token"`
Payloads []Payload `json:"data"`
}
type Payload struct {
// [redacted]
}
func (p *Payload) UploadToS3() error {
// the storageFolder method ensures that there are no name collision in
// case we get same timestamp in the key name
storage_path := fmt.Sprintf("%v/%v", p.storageFolder, time.Now().UnixNano())
bucket := S3Bucket
b := new(bytes.Buffer)
encodeErr := json.NewEncoder(b).Encode(payload)
if encodeErr != nil {
return encodeErr
}
// Everything we post to the S3 bucket should be marked 'private'
var acl = s3.Private
var contentType = "application/octet-stream"
return bucket.PutReader(storage_path, b, int64(b.Len()), contentType, acl, s3.Options{})
}
本地Go routines方法
剛開始,我們采用了一個非常本地化的POST處理實現(xiàn),僅僅嘗試把發(fā)到簡單go routine的job并行化:
func payloadHandler(w http.ResponseWriter, r *http.Request) {
if r.Method != "POST" {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
// Read the body into a string for json decoding
var content = PayloadCollection{}
err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)
if err != nil {
w.Header().Set("Content-Type", "application/json; charset=UTF-8")
w.WriteHeader(http.StatusBadRequest)
return
}
// Go through each payload and queue items individually to be posted to S3
for _, payload := range content.Payloads {
go payload.UploadToS3() // ----- DON'T DO THIS
}
w.WriteHeader(http.StatusOK)
}
對于中小負載,這會對大多數(shù)的人適用,但是大規(guī)模下,這個方案會很快被證明不是很好用。我們期望的請求數(shù),不在我們剛開始計劃的數(shù)量級,當(dāng)我們把第一個版本部署到生產(chǎn)環(huán)境上。我們完全低估了流量。
上面的方案在很多地方很不好。沒有辦法控制我們產(chǎn)生的go routine的數(shù)量。由于我們收到了每分鐘1百萬的POST請求,這段代碼很快就崩潰了。
再次嘗試
我們需要找一個不同的方式。自開始我們就討論過, 我們需要保持請求處理程序的生命周期很短,并且進程在后臺產(chǎn)生。當(dāng)然,這是你在Ruby on Rails的世界里必須要做的事情,否則你會阻塞在所有可用的工作 web處理器上,不管你是使用puma、unicore還是passenger(我們不要討論JRuby這個話題)。然后我們需要利用常用的處理方案來做這些,比如Resque、 Sidekiq、 SQS等。這個列表會繼續(xù)保留,因為有很多的方案可以實現(xiàn)這些。
所以,第二次迭代,我們創(chuàng)建了一個緩沖channel,我們可以把job排隊,然后把它們上傳到S3。因為我們可以控制我們隊列中的item最大值,我們有大量的內(nèi)存來排列job,我們認為只要把job在channel里面緩沖就可以了。
var Queue chan Payload
func init() {
Queue = make(chan Payload, MAX_QUEUE)
}
func payloadHandler(w http.ResponseWriter, r *http.Request) {
...
// Go through each payload and queue items individually to be posted to S3
for _, payload := range content.Payloads {
Queue - payload
}
...
}
接下來,我們再從隊列中取job,然后處理它們。我們使用類似于下面的代碼:
func StartProcessor() {
for {
select {
case job := -Queue:
job.payload.UploadToS3() // -- STILL NOT GOOD
}
}
}
說實話,我不知道我們在想什么。這肯定是一個滿是Red-Bulls的夜晚。這個方法不會帶來什么改善,我們用了一個 有缺陷的緩沖隊列并發(fā),僅僅是把問題推遲了。我們的同步處理器同時僅僅會上傳一個數(shù)據(jù)到S3,因為來到的請求遠遠大于單核處理器上傳到S3的能力,我們的帶緩沖channel很快達到了它的極限,然后阻塞了請求處理邏輯的queue更多item的能力。
我們僅僅避免了問題,同時開始了我們的系統(tǒng)掛掉的倒計時。當(dāng)部署了這個有缺陷的版本后,我們的延時保持在每分鐘以常量增長。
最好的解決方案
我們討論過在使用用Go channel時利用一種常用的模式,來創(chuàng)建一個二級channel系統(tǒng),一個來queue job,另外一個來控制使用多少個worker來并發(fā)操作JobQueue。
想法是,以一個恒定速率并行上傳到S3,既不會導(dǎo)致機器崩潰也不好產(chǎn)生S3的連接錯誤。這樣我們選擇了創(chuàng)建一個Job/Worker模式。對于那些熟悉Java、C#等語言的開發(fā)者,可以把這種模式想象成利用channel以golang的方式來實現(xiàn)了一個worker線程池,作為一種替代。
var (
MaxWorker = os.Getenv("MAX_WORKERS")
MaxQueue = os.Getenv("MAX_QUEUE")
)
// Job represents the job to be run
type Job struct {
Payload Payload
}
// A buffered channel that we can send work requests on.
var JobQueue chan Job
// Worker represents the worker that executes the job
type Worker struct {
WorkerPool chan chan Job
JobChannel chan Job
quit chan bool
}
func NewWorker(workerPool chan chan Job) Worker {
return Worker{
WorkerPool: workerPool,
JobChannel: make(chan Job),
quit: make(chan bool)}
}
// Start method starts the run loop for the worker, listening for a quit channel in
// case we need to stop it
func (w Worker) Start() {
go func() {
for {
// register the current worker into the worker queue.
w.WorkerPool - w.JobChannel
select {
case job := -w.JobChannel:
// we have received a work request.
if err := job.Payload.UploadToS3(); err != nil {
log.Errorf("Error uploading to S3: %s", err.Error())
}
case -w.quit:
// we have received a signal to stop
return
}
}
}()
}
// Stop signals the worker to stop listening for work requests.
func (w Worker) Stop() {
go func() {
w.quit - true
}()
}
我們已經(jīng)修改了我們的web請求handler,用payload創(chuàng)建一個Job實例,然后發(fā)到JobQueue channel,以便于worker來獲取。
func payloadHandler(w http.ResponseWriter, r *http.Request) {
if r.Method != "POST" {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
// Read the body into a string for json decoding
var content = PayloadCollection{}
err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(content)
if err != nil {
w.Header().Set("Content-Type", "application/json; charset=UTF-8")
w.WriteHeader(http.StatusBadRequest)
return
}
// Go through each payload and queue items individually to be posted to S3
for _, payload := range content.Payloads {
// let's create a job with the payload
work := Job{Payload: payload}
// Push the work onto the queue.
JobQueue - work
}
w.WriteHeader(http.StatusOK)
}
在web server初始化時,我們創(chuàng)建一個Dispatcher,然后調(diào)用Run()函數(shù)創(chuàng)建一個worker池子,然后開始監(jiān)聽JobQueue中的job。
dispatcher := NewDispatcher(MaxWorker)
dispatcher.Run()
下面是dispatcher的實現(xiàn)代碼:
type Dispatcher struct {
// A pool of workers channels that are registered with the dispatcher
WorkerPool chan chan Job
}
func NewDispatcher(maxWorkers int) *Dispatcher {
pool := make(chan chan Job, maxWorkers)
return Dispatcher{WorkerPool: pool}
}
func (d *Dispatcher) Run() {
// starting n number of workers
for i := 0; i d.maxWorkers; i++ {
worker := NewWorker(d.pool)
worker.Start()
}
go d.dispatch()
}
func (d *Dispatcher) dispatch() {
for {
select {
case job := -JobQueue:
// a job request has been received
go func(job Job) {
// try to obtain a worker job channel that is available.
// this will block until a worker is idle
jobChannel := -d.WorkerPool
// dispatch the job to the worker job channel
jobChannel - job
}(job)
}
}
}
注意到,我們提供了初始化并加入到池子的worker的最大數(shù)量。因為這個工程我們利用了Amazon Elasticbeanstalk帶有的docker化的Go環(huán)境,所以我們常常會遵守12-factor方法論來配置我們的生成環(huán)境中的系統(tǒng),我們從環(huán)境變了讀取這些值。這種方式,我們控制worker的數(shù)量和JobQueue的大小,所以我們可以很快的改變這些值,而不需要重新部署集群。
var (
MaxWorker = os.Getenv("MAX_WORKERS")
MaxQueue = os.Getenv("MAX_QUEUE")
)
直接結(jié)果
我們部署了之后,立馬看到了延時降到微乎其微的數(shù)值,并未我們處理請求的能力提升很大。
Elastic Load Balancers完全啟動后,我們看到ElasticBeanstalk 應(yīng)用服務(wù)于每分鐘1百萬請求。通常情況下在上午時間有幾個小時,流量峰值超過每分鐘一百萬次。
我們一旦部署了新的代碼,服務(wù)器的數(shù)量從100臺大幅 下降到大約20臺。
我們合理配置了我們的集群和自動均衡配置之后,我們可以把服務(wù)器的數(shù)量降至4x EC2 c4.Large實例,并且Elastic Auto-Scaling設(shè)置為如果CPU達到5分鐘的90%利用率,我們就會產(chǎn)生新的實例。
總結(jié)
在我的書中,簡單總是獲勝。我們可以使用多隊列、后臺worker、復(fù)雜的部署設(shè)計一個復(fù)雜的系統(tǒng),但是我們決定利用Elasticbeanstalk 的auto-scaling的能力和Go語言開箱即用的特性簡化并發(fā)。
我們僅僅用了4臺機器,這并不是什么新鮮事了。可能它們還不如我的MacBook能力強大,但是卻處理了每分鐘1百萬的寫入到S3的請求。
處理問題有正確的工具。當(dāng)你的 Ruby on Rails 系統(tǒng)需要更強大的web handler時,可以考慮下ruby生態(tài)系統(tǒng)之外的技術(shù),或許可以得到更簡單但更強大的替代方案。
在CS:GO游戲中,庫存是指玩家擁有的各種物品,包括武器、背包、刀具等等。當(dāng)玩家購買了某個物品并放入庫存中時,該物品的倒計時就會開始。
倒計時通常是指物品可以進行交易的時間限制,也就是玩家購買物品后,需要等待一段時間才能進行交易。這是為了防止玩家通過非法手段獲取物品后立即出售,保證游戲的經(jīng)濟系統(tǒng)和穩(wěn)定性。
在CS:GO游戲中,庫存中的物品通常會有交易限制,有些物品需要等待7天,有些則需要30天或者更長的時間。在這段時間內(nèi),庫存中的物品將不能進行交易。
因此,在玩家查看CS:GO庫存中的物品時,會看到其倒計時時間,而倒計時時間結(jié)束后,物品就可以進行交易了。
漢語:倒計時英語:The countdown阿拉伯語: ???? ???????? 俄語: отсчет法語:Le compte à rebours韓語:?????日語:カウントダウン泰語:??????????德語:Countdown西班牙語:La cuenta regresiva阿爾巴尼亞語:Countdown波斯語:????? ?????希臘語:Αντ?στροφη μ?τρηση馬來語:undur拉丁語:turpis瑞典語:Nedr?knings波蘭語:odliczanie意大利語:conto alla rovescia土耳其語:geriye say?m冰島語:nieurtalning葡萄牙語:contagem regressiva越南語:??m ng??c約魯巴語:kika匈牙利語:visszaszámlálás希伯來語:????? ?????塞爾維亞語:Одбро?ава?е斯洛伐克語:odpo?ítavanie斯洛文尼亞語:od?tevanje立陶宛語:Atbulinis馬其頓語:одбро?ува?ето菲律賓語:Pagbibilang芬蘭語:l?ht?laskenta愛沙尼亞語:stardiloendus白俄羅斯語:зваротныадл?к世界語:Countdown????????????????????????????
分享名稱:go語言倒計時 go語言時間格式轉(zhuǎn)換
網(wǎng)頁網(wǎng)址:http://bm7419.com/article34/dohjjpe.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供移動網(wǎng)站建設(shè)、ChatGPT、Google、云服務(wù)器、虛擬主機、域名注冊
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)