Java 使用静态字典压缩字符串

这将是一个有点抽象的问题，因为我甚至不知道是否有这样的发展

假设我们有一个应用程序，它试图将文本数据从A点传递到B点。 A和B相距很远，所以数据的大小对我们要优化的所有重要指标（速度、延迟和吞吐量）都有重要影响。首先想到的是压缩，但是当我们必须压缩许多小消息时，压缩并不是那么有效，但是当压缩数据的大小很大时，压缩是非常有效的

我没有使用压缩算法的经验，但我的理解是，输入越大，压缩率越好，因为重复块和可以优化的内容的可能性越大

另一种方法是分批处理，通过等待N段时间，收集所有小消息并创建一个压缩的大消息，我们可以获得很好的压缩率，但我们会牺牲延迟，首先到达的消息将不必要地延迟N

我正在寻找的解决方案是这样的，当一个压缩算法遍历数据集时，它可能有一些它知道可以优化的东西的字典。每次我们完成压缩时，这个字典都会被扔掉，它总是和消息一起发送给B

rawMsg->[dictionary | compressedPayload]->发送到B

然而，如果我们可以在内存中维护这本词典，并且只在它发生变化时发送，这意味着我们可以有效地压缩即使是很小的消息，避免每次都将词典发送到另一端

rawMsg->compress（existingDictrionaryOfSomeVersion，rawMsg）->[dictionaryVersion | compressedPayload]->发送到B

显然，这里的假设是B也会保留dictionary的实例，并在新版本到来时不断更新它

请注意，像

protobuf

或

fix

（在金融应用程序中）这样的协议正是如此。 对于任何消息，您都有模式（字典），并且两端都可用，然后您只需发送原始二进制数据，既高效又快速，但您的模式是固定不变的

我正在寻找一些可以用于自由格式文本的东西

---

是否有任何技术允许这样做（无需固定模式）？

您只需在一个压缩流中发送许多小消息即可。然后，他们将能够利用以前的小消息历史。使用zlib，您可以清除每条消息，这将避免在传输之前必须等待整个数据块的建立。这会降低压缩性能，但不会像尝试单独压缩每个字符串那样多（这很可能最终会扩展它们）。就zlib而言，您的字典始终是您发送的最后32K条消息。

既然您要求推荐一个库，我认为您的问题最好放在软件推荐网站上：就个人而言，我不知道有哪种技术能够完全满足您的要求。最好是灵活地设计软件（“策略模式”），以便实际压缩能够很好地隔离，并且可以轻松地切换。如果需要较低的传输大小，则使用gzip压缩，但是如果需要传输大数据，则最好使用另一个线程并通过steam@markspace是这样设计的,，我不想插任何东西，但是gzip的结果不值得，特别是对于小消息。。。由于它是自由格式的文本，我不能只拿出一些protobuf msg…你试过snappy吗？这不是很好的压缩，但它是超级快速。也许你可以试一试…@slee忘了线程和常见场景优化我认为我做得很好，目前我有一个固定在特定核心上的专用线程，它能够以比消息到达更快的速度处理消息（序列化和压缩消息），我的瓶颈是网络，我不能只产生多个连接，我需要相同的订单。。。简言之，我需要在不进行批处理的情况下使有效负载显著减小…因此即使没有任何更改，它也始终传输字典？没有单独的字典可发送。“字典”只是最后32K个未压缩数据。