阅读技术文档的重要顺序和答疑的好处

技术文档的阅读应该从原理开始，也就是构架。

先了解构架然后了解方法，就是一种正确的因果论，以及一种理论指导实践，实践反过来强化理论的顺序。

那种感觉就像是一下子串联出了所有相关联的小家伙，一拉拉一串的感觉。

是在了解GCP的Pub/Sub的原理的时候了解到的。

周日的时候我还是只想知道具体这个服务怎么操作，想要赶紧具像化它的操作过程。然后开始用自己的方式解释问题，结果发现自己也解释不清楚到底这个服务的pull是什么。然后终于以我自己能接受的解释方式解释了这个问题后，发现藤原老师的问题我又解释不清楚了。为什么在error处理页面，依然是说要再push延迟，明明是一个pull的问题。

我发现藤原老师的问题集中在，为什么pull还是需要被推送。明明是拉取何来的推送？这看起来就像是一个不合理的语言问题。

是的，我们的问题，人类的最大问题就是想当然，看着一个单词的字面意思，就以为自己已经知道了这个构架是什么样的了。

让我意识到问题只是集中在不明白pull为什么会需要重新发送，这一点的时候，我想我应该去研究一下构架了。于是我一眼就看到了官方文档的构架那部分，一点都不多，我用五到十分钟，理解了pull和push的工作机制，竟然是如此的简单。pull其实就像是TCP通信一样，进行握手，push只是对你的客户端进行不停的post操作。

而且我也误会了服务端可客户端到底是谁，我以为是topic和subscriber，但是其实是三个主体。

Client，Subscriber，Topic。

所谓的pull是C向S发出pull的请求，pull的主体是S，pull的对象是T。

所谓的push是C是push的对象，因为有一个endpoint在自己这里，push的主体是subscriber，push的内容是持续不断的从T拉取来的。

太棒了，我想我还需要查查SQS的不同之处。

关于答疑的好处，我感受到的是，在我自己去回答别人的Spark的问题，还是针对山崎老师的关于Snowflake的PrivateLink的构架问题，我自己的解释和追究，都是一种非常好的将构架落到实处的方法。

是一种深度思考，总结。

以此记录。