我最近开始玩弄 akka 的演员和 http 模块。但是，我偶然发现了一个相当烦人的小怪癖，即创建单人演员。
这里有两个例子：
1)
我有一个内存缓存，我的服务很小（它是一个应用程序）所以我真的很喜欢内存模型。我可以在地图中保存与用户相关的大多数信息（嗯，列表地图，但仍然很容易推理结构），而且我没有得到 redis、geode 或 aerospike 的开销和复杂性。
唯一的问题是这个内存中的缓存可以被多个来源修改，并且所述修改必须是同步的。而不是同步这个结构的所有 3 种访问方法（例如，通过构建消息队列或实现锁），我想我只是将结构及其访问方法包装到一个参与者中，构建消息队列，简单的接收->发送逻辑和如果事情扩大，将很容易在专用内存数据库上用 DA 演员替换。
2）我有一个“服务”层，应该用于为各种作业分派演员（访问数据库，访问内存缓存，使用数据进行计算并将结果传递给用户......等等）。
将这个服务层理解为某种“单例”，对某些功能的闭包是有意义的，因为它没有以任何方式阻塞或 CPU/内存密集型，它只是简单地分配任务（例如，决定有多少演员/线程/我们应该被创建以及请求应该去哪里）
但是，这需要：
a) 制作两个对象单例演员或
b）使两个对象都成为实际的“对象”（如在 scala 对象表示法中，它指定一个命名的单例，其函数在其范围内具有闭包）
b) 有很多问题，即服务层要么必须将参与者系统“传递”给它（我不确定这是最佳实践）才能创建参与者，而不是创建自己的参与者“儿童”将使用全球参与者系统创建儿童，并且消息传递和监控逻辑将更加尴尬和不直观。此外，内存缓存不会具有内置消息队列的优势（我并不是说它很难实现，但这似乎是一种情况，即“哦，快乐，这很好我有演员，我不必花时间实现和测试这段代码”）
a) 似乎有一个问题，一般来说，akka 文档中的文档记录很差，并且没有得到建议。我是说：
http://doc.akka.io/docs/akka/2.4/scala/cluster-singleton.html
看看这个狗屎，一半的文档警告不要使用它，它是它自己的依赖项，坦率地说，对于像我这样没有涉足函数式并发编程象牙塔的可怜草皮来说，它很难阅读。
所以，嗯。你们中的任何人都可以向我解释为什么使用单身演员不好吗？如果单身人士不能成为演员，你如何设计他们？有没有什么方法可以设计出不会造成很大伤害的单例演员？具有被称为而不是实例化的“un akka like”的“全局”服务的整个“服务”模型？