Naive approach to splitting requests

<p>Hello,</p> <p>I&#39;m trying to split requests after every X requests and I&#39;m afraid my current approach is very naive. </p> <p>Right now I simply increase a counter after every request, but I&#39;m afraid it&#39;s not very accurate with a lot of concurrent requests, is it? </p> <p>What would be the correct approach? </p> <p>Regards</p> <hr/>**评论：**<br/><br/>TheMerovius: <pre><p>What is the goal? You said that your approach isn&#39;t very accurate with lots of concurrent requests, but say you want to split every N requests, you receive N-1 sequential ones and then 2 requests concurrently - which one should be considered the &#34;Nth&#34;?</p> <p>FWIW, the word &#34;concurrently&#34; is, in a way, CS-lingo for &#34;incomparable in a partial order derived from time&#34;. I.e. by definition, you can&#39;t say that one concurrent request arrived &#34;before&#34; the other. And given, that there is only a partial order on events, things like &#34;after N requests&#34; doesn&#39;t make inherent sense.</p> <p>So, the tl;dr is: Depending on what specifically you mean by &#34;splitting&#34;, &#34;after X requests&#34; and what the actual underlying goal is (sampling? load balancing?) your approach is probably fine.</p> <p>You could use, for example, <a href="https://godoc.org/sync/atomic#AddUint64" rel="nofollow">sync/atomic</a> as a counter and see whether <code>new % X == 0</code>. That would provide you with a total order of requests, so &#34;every X requests&#34; would be well-defined and that definition is probably as good as any other you could come up with.</p> <p>(now, a different question would be, what happens if you have more than one process, as they won&#39;t be able to have a single atomic counter. To design that, the actual use case would be required though)</p> <p>Hope that helps somewhat :)</p></pre>