mirror of
https://github.com/chai2010/advanced-go-programming-book.git
synced 2025-05-24 04:22:22 +00:00
fix ch6
This commit is contained in:
Xargin
parent
7c910bd78d
commit
3506dcd652
@ -10,7 +10,7 @@
|
||||
|
||||
|
||||
- 作者：柴树杉，Github [@chai2010](https://github.com/chai2010)，Twitter [@chaishushan](https://twitter.com/chaishushan)，主页 https://chai2010.cn/about
|
||||
- 作者：曹春晖，Github [@cch123](https://github.com/cch123)
|
||||
- 作者：曹春晖，Github [@cch123](https://github.com/cch123)，主页 http:://xargin.com
|
||||
- 网址：https://github.com/chai2010/advanced-go-programming-book
|
||||
- Star历史：https://starcharts.herokuapp.com/chai2010/advanced-go-programming-book.svg
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# 6.1 分布式 id 生成器
|
||||
# 6.1 分布式id生成器
|
||||
|
||||
有时我们需要能够生成类似MySQL自增ID这样不断增大，同时又不会重复的id。以支持业务中的高并发场景。比较典型的，电商促销时，短时间内会有大量的订单涌入到系统，比如每秒10w+。明星出轨时，会有大量热情的粉丝发微博以表心意，同样会在短时间内产生大量的消息。
|
||||
|
||||
@ -45,7 +45,7 @@ mysql> select last_insert_id();
|
||||
|
||||
## 6.1.2 开源实例
|
||||
|
||||
### 6.1.2.1 标准 snowflake 实现
|
||||
### 6.1.2.1 标准snowflake实现
|
||||
|
||||
`github.com/bwmarrin/snowflake` 是一个相当轻量化的snowflake的Go实现。其文档对各位使用的定义见*图 6-2*所示。
|
||||
|
||||
|
||||
@ -269,7 +269,7 @@ func main() {
|
||||
|
||||
这种分布式的阻塞锁比较适合分布式任务调度场景，但不适合高频次持锁时间短的抢锁场景。按照Google的Chubby论文里的阐述，基于强一致协议的锁适用于`粗粒度`的加锁操作。这里的粗粒度指锁占用时间较长。我们在使用时也应思考在自己的业务场景中使用是否合适。
|
||||
|
||||
## 6.2.5 基于 etcd
|
||||
## 6.2.5 基于etcd
|
||||
|
||||
etcd是分布式系统中，功能上与ZooKeeper类似的组件，这两年越来越火了。上面基于ZooKeeper我们实现了分布式阻塞锁，基于etcd，也可以实现类似的功能：
|
||||
|
||||
@ -315,7 +315,7 @@ etcd中没有像ZooKeeper那样的Sequence节点。所以其锁实现和基于Zo
|
||||
|
||||
值得一提的是，在etcdv3的API中官方已经提供了可以直接使用的锁API，读者可以查阅etcd的文档做进一步的学习。
|
||||
|
||||
## 6.2.7 如何选择
|
||||
## 6.2.7 如何选择合适的锁
|
||||
|
||||
业务还在单机就可以搞定的量级时，那么按照需求使用任意的单机锁方案就可以。
|
||||
|
||||
|
||||
@ -20,7 +20,7 @@
|
||||
|
||||
再举个例子，互联网公司的运营系统中会有各种类型的运营活动，有些运营活动推出后可能出现了超出预期的事件（比如公关危机），需要紧急将系统下线。这时候会用到一些开关来快速关闭相应的功能。或者快速将想要剔除的活动id从白名单中剔除。在Web章节中的AB测试一节中，我们也提到，有时需要有这样的系统来告诉我们当前需要放多少流量到相应的功能代码上。我们可以像那一节中，使用远程RPC来获知这些信息，但同时，也可以结合分布式配置系统，主动地拉取到这些信息。
|
||||
|
||||
## 6.6.2 使用 etcd 实现配置更新
|
||||
## 6.6.2 使用etcd实现配置更新
|
||||
|
||||
我们使用etcd实现一个简单的配置读取和动态更新流程，以此来了解线上的配置更新流程。
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
作为收集数据的前置工作，有能力去写一个简单的或者复杂的爬虫，对于我们来说依然非常重要。
|
||||
|
||||
## 基于colly的单机爬虫
|
||||
## 6.7.1 基于colly的单机爬虫
|
||||
|
||||
《Go 语言编程》一书给出了简单的爬虫示例，经过了多年的发展，现在使用Go语言写一个网站的爬虫要更加方便，比如用colly来实现爬取某网站（虚拟站点，这里用abcdefg作为占位符）在Go语言标签下的前十页内容：
|
||||
|
||||
@ -67,7 +67,7 @@ func main() {
|
||||
}
|
||||
```
|
||||
|
||||
## 分布式爬虫
|
||||
## 6.7.2 分布式爬虫
|
||||
|
||||
想像一下，你们的信息分析系统运行非常之快。获取信息的速度成为了瓶颈，虽然可以用上Go语言所有优秀的并发特性，将单机的CPU和网络带宽都用满，但还是希望能够加快爬虫的爬取速度。在很多场景下，速度是有意义的：
|
||||
|
||||
@ -86,7 +86,7 @@ func main() {
|
||||
|
||||
本节我们来简单实现一个基于消息队列的爬虫，本节我们使用nats来做任务分发。实际开发中，应该针对自己的业务对消息本身的可靠性要求和公司的基础架构组件情况进行选型。
|
||||
|
||||
### nats 简介
|
||||
### 6.7.2.1 nats简介
|
||||
|
||||
nats是Go实现的一个高性能分布式消息队列，适用于高并发高吞吐量的消息分发场景。早期的nats以速度为重，没有支持持久化。从16年开始，nats通过nats-streaming支持基于日志的持久化，以及可靠的消息传输。为了演示方便，我们本节中只使用nats。
|
||||
|
||||
@ -145,7 +145,7 @@ for {
|
||||
}
|
||||
```
|
||||
|
||||
#### 结合colly的消息生产
|
||||
## 6.7.3 结合nats和colly的消息生产
|
||||
|
||||
我们为每一个网站定制一个对应的collector，并设置相应的规则，比如abcdefg，hijklmn（虚构的），再用简单的工厂方法来将该collector和其host对应起来，每个站点爬到列表页之后，需要在当前程序中把所有链接解析出来，并把落地页的URL发往消息队列。
|
||||
|
||||
@ -229,7 +229,7 @@ func main() {
|
||||
|
||||
```
|
||||
|
||||
#### 结合 colly 的消息消费
|
||||
## 6.7.4 结合colly的消息消费
|
||||
|
||||
消费端就简单一些了，我们只需要订阅对应的主题，并直接访问网站的详情页(落地页)即可。
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user