我解决了遇到的其中一个问题，需要帮助进一步调整以获得性能。
会有一个apache模块通过http协议接收请求，并在几毫秒内响应。 它处理input参数并将其作为JSONlogging放入caching层。 （目前文本文件被用作caching）。
另一个asynchronous模块读取JSONlogging，烹饪并将它们推送到MongoDB中。 这可以避免由于MongoDB性能下降而导致的http响应延迟。
在Load Balancer下将会有多个机器（目前是12个），并且预计每天将有100 M个请求，当JSONlogging被写入文本文件时，这个请求的大小将会是〜10-15 GB。
基本上我正在寻找更好的数据摄取解决scheme。
关于在生产者消费者体系结构中使用ZeroMQ或RabbitMQ，
消息队列位于内存队列中，可能无法在内存中占用这么多数据。
在MongoDB中使用的数据是重要的数据，如果消息队列由于某种原因停机/崩溃，我们不会花费成本。
请build议。
看起来在两种情况下，每个线程都与其他模块中的匹配线程（通过固定文件或偏移量）耦合 – 这意味着，如果其中一个模块本质上比另一个模块更慢，则仍然会遇到瓶颈更快的模块将被利用不足。
相反，您可以使用任务队列（或多个生产者的类似解决方案 – 多个消费者问题），并让每个线程在任何可用的任务变为空闲时从中进行选择。 这将使您在平衡每个模块中的线程数量方面拥有更大的自由度。 如果前端http模块的速度比后端处理速度快2倍，则可以产生2个以上的后端线程。
“价格”是你需要安全地维护共享队列（锁定等），并确保它有效地完成，没有死锁。
您可以使用像RabbitMQ或ZeroMQ这样的东西，并使用批量数据插入到您的数据库，或扩展到其他服务器根据需要。
您创建HTTP接收器线程来接收要记录的数据，将传入的数据推送到内存中的接收队列。 你创建了一个单独的数据库写程序线程，它除了接收所有接收到的数据（由接收者线程）在内存中排队，将它们转换为单行数据库INSERT，并在单个事务中发送它们之后，事务完成后，它返回到另一批接收数据的队列（队列在前一个事务正在进行时收集数据）。 将多个INSERT事务并行发送到单个数据库表只会在特殊情况下产生更高的吞吐量，这就是为什么单个写入程序线程通常是不错的选择。 将多个INSERT组合到一个事务中将更好地利用HDD的有限I / O功能。