随机用户跟踪

随机用户跟踪的目的

用户跟踪相对于日志的优势是：将用户的流程，按照时序，上报到一个集中的点。上报的内容不局限于消息，也可以在一些关键点上报一些上下文信息，上报一些错误信息。用户跟踪能够比日志更方便地定位问题。
但是，当系统中有很多用户的时候，我们是不容易知道哪些用户发生了故障。这时候，可以借助随机用户跟踪，一段时间内跟踪用户A，下一段时间跟踪用户B，再下一段时间跟踪用户C……这样随机用户跟踪可能会跟踪到发生错误的用户，继而再打开用户跟踪继续定位。

如何随机

方式1：在doManager中随机找一个do。
方式2：抢占式，过了一段时间（如2min），下一时刻谁先来，就选谁。

如何共享/通知被随机的用户

方式1：共享变量（ds/do为actor的时候，违背了架构原则）
方式2：消息通知（ds通过消息通知do）

何时更新被随机的用户

ds收到消息，并通知do的时候。即scheduleDoAndReport()中调用checkAndChangeRandomUser()来更新被随机跟踪的用户。

性能问题

1、ds通知do当前被随机的用户时，可以告诉所有的do，但是这样开销比较大。其实，只需通知即将被随机跟踪的用户它将要被随机跟踪，然后告诉上一时间段被随机跟踪的用户它将不被跟踪了即可。
2、即使只通知者两个用户，也有性能开销的。这时候，可以在创建跟踪的任务回调函数中设置随机用户跟踪的开关，那么checkAndChangeRandomUser()就可以跟踪开关选择是否需要通知do。

do收到通知后的处理

1、userTrace中更新RandomUser，决定是否要上报。
2、因为HTTP中没有用户的概念，只做消息的转发。所以，需要将发送的HTTP消息中增加用户信息。但是HTTP消息的发送点，无法取得userTrace中的RandomUser。这时候，可将RandomUser放在ConfigRole中，这样发送HTTP消息的地方，也可以获得RandomUser。需要将每条消息的User和RandomUser信息在HTTP消息头中带给HTTP，HTTP据此决定是否上报跟踪和随机跟踪。

兼容do的actor形态和非actor形态

actor形态的do，userTrace的实例是每个do独自创建的，是独占的。而非actor形态的do，userTrace实例是ds赋值给do的，是共享的。这样，在非actor形态下，通知新的do设置了被随机跟踪的用户，通知旧的do，清空了被随机跟踪的用户，就不行了。为了兼容这两种形态，可以先清空旧的，再通知新的。