mirror of
https://github.com/unknwon/the-way-to-go_ZH_CN.git
synced 2025-08-12 06:36:43 +08:00
Update 14.5.md
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
# 14.5 通道,超时和断续器(Ticker)
|
||||
# 14.5 通道,超时和计时器(Ticker)
|
||||
|
||||
`time`包中有一些有趣的功能可以和通道组合使用。
|
||||
|
||||
@@ -14,7 +14,7 @@ type Ticker struct {
|
||||
|
||||
在协程周期性的执行一些事情(打印状态日志,输出,计算等等)的时候非常有用。
|
||||
|
||||
调用`Stop()`使断续器停止,在`defer`语句中使用。这些都很好的适应`select`语句:
|
||||
调用`Stop()`使计时器停止,在`defer`语句中使用。这些都很好的适应`select`语句:
|
||||
```go
|
||||
ticker := time.NewTicker(updateInterval)
|
||||
defer ticker.Stop()
|
||||
@@ -45,9 +45,9 @@ for req := range requests {
|
||||
```
|
||||
这样只会按照指定频率处理请求:`chRate`阻塞了更高的频率。每秒处理的频率可以根据机器负载(和/或)资源的情况而增加或减少。
|
||||
|
||||
问题14.1:扩展上边的代码,思考如何承载周期请求数的暴增(提示:使用带缓冲通道和断续器对象)。
|
||||
问题14.1:扩展上边的代码,思考如何承载周期请求数的暴增(提示:使用带缓冲通道和计时器对象)。
|
||||
|
||||
计时器(TImer)结构体看上去和断续器(Ticker)结构体的确很像(构造为`NewTimer(d Duration)`)),但是它只发送一次时间,在`Dration d`之后。
|
||||
定时器(TImer)结构体看上去和计时器(Ticker)结构体的确很像(构造为`NewTimer(d Duration)`)),但是它只发送一次时间,在`Dration d`之后。
|
||||
|
||||
还有`time.After(d)`函数,声明如下:
|
||||
```go
|
||||
@@ -156,7 +156,7 @@ func Query(conns []conn, query string) Result {
|
||||
|
||||
在应用中缓存数据:
|
||||
|
||||
应用程序中用到了来自数据库(或者常见的数据存储)的数据时,经常会把数据缓存到内存中,因为从数据库中获取数据的操作代价很高;如果数据库中的值不发生变化就没有问题。但是如果值有变化,我们需要一个机制来周期性的从数据库重新读取这些值:缓存的值就不可用(过期)了,而且我们也不希望用户看到陈旧的数据。这篇文章:[http://www.tideland.biz/CachingValues](http://www.tideland.biz/CachingValues)(译者注:这个网页已经失效了)讨论了一种方式,使用协程和断续器对象来实现。
|
||||
应用程序中用到了来自数据库(或者常见的数据存储)的数据时,经常会把数据缓存到内存中,因为从数据库中获取数据的操作代价很高;如果数据库中的值不发生变化就没有问题。但是如果值有变化,我们需要一个机制来周期性的从数据库重新读取这些值:缓存的值就不可用(过期)了,而且我们也不希望用户看到陈旧的数据。这篇文章:[http://www.tideland.biz/CachingValues](http://www.tideland.biz/CachingValues)(译者注:这个网页已经失效了)讨论了一种方式,使用协程和计时器对象来实现。
|
||||
|
||||
## 链接
|
||||
|
||||
|
Reference in New Issue
Block a user