[hornetq-commits] JBoss hornetq SVN: r9206 - branches/HnetQ_323_cn/docs/user-manual/zh.

Author: gaohoward Date: 2010-05-07 01:58:16 -0400 (Fri, 07 May 2010) New Revision: 9206 Modified: branches/HnetQ_323_cn/docs/user-manual/zh/duplicate-detection.xml Log: done Modified: branches/HnetQ_323_cn/docs/user-manual/zh/duplicate-detection.xml =================================================================== --- branches/HnetQ_323_cn/docs/user-manual/zh/duplicate-detection.xml 2010-05-06 16:18:59 UTC (rev 9205) +++ branches/HnetQ_323_cn/docs/user-manual/zh/duplicate-detection.xml 2010-05-07 05:58:16 UTC (rev 9206) @@ -19,58 +19,39 @@ <!-- ============================================================================= --> <chapter id="duplicate-detection"> - <title>Duplicate Message Detection</title> - <para>HornetQ includes powerful automatic duplicate message detection, filtering out - duplicate messages without you having to code your own fiddly duplicate detection logic at - the application level. This chapter will explain what duplicate detection is, how HornetQ - uses it and how and where to configure it.</para> - <para>When sending messages from a client to a server, or indeed from a server to another - server, if the target server or connection fails sometime after sending the message, but - before the sender receives a response that the send (or commit) was processed successfully - then the sender cannot know for sure if the message was sent successfully to the - address.</para> - <para>If the target server or connection failed after the send was received and processed but - before the response was sent back then the message will have been sent to the address - successfully, but if the target server or connection failed before the send was received and - finished processing then it will not have been sent to the address successfully. From the - senders point of view it's not possible to distinguish these two cases.</para> - <para>When the server recovers this leaves the client in a difficult situation. It knows the - target server failed, but it does not know if the last message reached its destination ok. - If it decides to resend the last message, then that could result in a duplicate message - being sent to the address. If each message was an order or a trade then this could result in - the order being fulfilled twice or the trade being double booked. This is clearly not a - desirable situation.</para> - <para>Sending the message(s) in a transaction does not help out either. If the server or - connection fails while the transaction commit is being processed it is also indeterminate - whether the transaction was successfully committed or not!</para> - <para>To solve these issues HornetQ provides automatic duplicate messages detection for - messages sent to addresses.</para> + <title>重复消息检测</title> + <para>HornetQ具有强大的自动检测重复消息的功能。应用层无需实现复杂的重复检测。本章解释了什么是重复检测，它 + 在HornetQ中如何工作的，以及如何进行配置。</para> + <para>当客户端向服务器端发送消息时，或者从一个服务器向另一个服务器传递消息时，如果消息发送后目标服务器或者 + 连接出现故障，导致发送一方没有收到发送成功的确认信息，发送方因此就无法确定消息是否已经成功发送到了目标地 + 址。</para> + <para>如果上述的故障发生在消息被成功接收并处理后，但是在向发送方返回功能确认信息之前，那么消息实际上可以到达 + 其目的地址；如果故障发生在消息的接收及处理过程中，则消息不会到达其目的地址。从发送方的角度看，它无法区分 + 这两种情况。</para> + <para>当服务器恢复后，客户端面临的困难的选择。它知道服务器出了故障，但是不知道刚刚发送的消息是否成功到达目的 + 地址。如果它重新发送这个消息，就有可能造成消息的重复。如果这个消息是一个订单的话，重复发送消息就会产生两 + 个相同的订单，这当然不是所希望的結果。</para> + <para>将消息的发送放到一个事务中也不能解决这个问题。如果在事务提交的过程中发生故障，同样不能确定这个事务是否提交 + 成功！</para> + <para>为了解决这个问题，HornetQ提供了自动消息重复检测功能。</para> <section> - <title>Using Duplicate Detection for Message Sending</title> - <para>Enabling duplicate message detection for sent messages is simple: you just need to set - a special property on the message to a unique value. You can create the value however - you like, as long as it is unique. When the target server receives the message it will - check if that property is set, if it is, then it will check in its in memory cache if it - has already received a message with that value of the header. If it has received a - message with the same value before then it will ignore the message.</para> + <title>在消息发送中应用重复检测</title> + <para>在消息发送中启用重复检测功能十分简单：你只需将消息的一个特殊属性设置一个唯一值。你可以用任意方法来 + 计算这个值，但是要保证它的唯一性。当目标服务器接收到这个消息时，它会检查这个属性是否被设置，如果设置了， + 就检查内存缓存中是否已经接收到了相同值的消息。如果发现已经接收过具有相同属性值的消息，它将忽略这个消息。</para> <note> - <para>Using duplicate detection to move messages between nodes can give you the same - <emphasis>once and only once</emphasis> delivery guarantees as if you were using - an XA transaction to consume messages from source and send them to the target, but - with less overhead and much easier configuration than using XA.</para> + <para>在节点之间的消息传递使用重复消息检测可以保证<emphasis>一次且只一次</emphasis>的传递，和使用 + XA事务接收消息的效果一样，但是比XA消耗的资源要少，并且更容易。</para> </note> - <para>If you're sending messages in a transaction then you don't have to set the property - for <emphasis>every</emphasis> message you send in that transaction, you only need to - set it once in the transaction. If the server detects a duplicate message for any - message in the transaction, then it will ignore the entire transaction.</para> - <para>The name of the property that you set is given by the value of <literal - >org.hornetq.core.message.impl.HDR_DUPLICATE_DETECTION_ID</literal>, which - is <literal>_HQ_DUPL_ID</literal></para> - <para>The value of the property can be of type <literal>byte[]</literal> or <literal - >SimpleString</literal> if you're using the core API. If you're using JMS it must be - a <literal>String</literal>, and its value should be unique. An easy way of generating - a unique id is by generating a UUID.</para> - <para>Here's an example of setting the property using the core API:</para> + <para>如果是在一个事务中发送消息，则只需要设置其中一个消息的属性值。在服务器端如果服务器检测到一个事务中某一个 + 消息重复，则会忽略整个事务。</para> + <para>这个属性的名称由<literal + >org.hornetq.api.core.HDR_DUPLICATE_DETECTION_ID</literal>定义，即： + <literal>_HQ_DUPL_ID</literal>。</para> + <para>该属性的值可以是<literal>byte[]</literal>类型或<literal + >SimpleString</literal>类型（核心接口）。如果使用JMS，它必须是<literal>String</literal> + 类型。它的值一定是唯一的。一个简单的方法是使用UUID。</para> + <para>下面是一个使用核心接口设置这个属性的例子：</para> <programlisting> ... @@ -82,7 +63,7 @@ ... </programlisting> - <para>And here's an example using the JMS API:</para> + <para>下面则是一个使用JMS的例子：</para> <programlisting> ... @@ -96,59 +77,44 @@ </programlisting> </section> <section id="duplicate.id.cache"> - <title>Configuring the Duplicate ID Cache</title> - <para>The server maintains caches of received values of the <literal - >org.hornetq.core.message.impl.HDR_DUPLICATE_DETECTION_ID</literal> property - sent to each address. Each address has its own distinct cache.</para> - <para>The cache is a circular fixed size cache. If the cache has a maximum size of <literal - >n</literal> elements, then the <literal>n + 1</literal>th id stored will overwrite - the <literal>0</literal>th element in the cache.</para> - <para>The maximum size of the cache is configured by the parameter <literal - >id-cache-size</literal> in <literal>hornetq-configuration.xml</literal>, the default - value is <literal>2000</literal> elements.</para> - <para>The caches can also be configured to persist to disk or not. This is configured by the - parameter <literal>persist-id-cache</literal>, also in <literal - >hornetq-configuration.xml</literal>. If this is set to <literal>true</literal> then - each id will be persisted to permanent storage as they are received. The default value - for this parameter is <literal>true</literal>.</para> + <title>配置重复ID缓存</title> + <para>服务器缓存中保存接收到的消息的<literal + >org.hornetq.core.message.impl.HDR_DUPLICATE_DETECTION_ID</literal>属性值。每个地址有 + 单独的缓存。</para> + <para>缓存的大小是固定的，循环使用。如果缓存的最大可以存放<literal + >n</literal>条记录，那么<literal>n + 1</literal>条记录将会覆盖缓存中的第<literal>0</literal> + 条记录。</para> + <para>缓存的最大容量在文件<literal>hornetq-configuration.xml</literal>中配置，参数是<literal + >id-cache-size</literal>。默认值是<literal>2000</literal>条记录。</para> + <para>在文件<literal>hornetq-configuration.xml</literal>中还可以配置将缓存持久化到磁盘。相应的参数 + 是<literal>persist-id-cache</literal>。如果设为<literal>true</literal>，则每加入一个id就将 + 它同时保存到磁盘中。默认值是<literal>true</literal>。</para> <note> - <para>When choosing a size of the duplicate id cache be sure to set it to a larger - enough size so if you resend messages all the previously sent ones are in the cache - not having been overwritten.</para> + <para>注意在设置缓存大小时，一定要保证缓存能保存足夠数量的记录，当消息被重新发送时，之前发送的ID不被 + 覆盖掉。</para> </note> </section> <section> - <title>Duplicate Detection and Bridges</title> - <para>Core bridges can be configured to automatically add a unique duplicate id value (if there - isn't already one in the message) before forwarding the message to it's target. This - ensures that if the target server crashes or the connection is interrupted and the - bridge resends the message, then if it has already been received by the target server, - it will be ignored.</para> - <para>To configure a core bridge to add the duplicate id header, simply set the <parameter - >use-duplicate-detection</parameter> to <literal>true</literal> when configuring a - bridge in <literal>hornetq-configuration.xml</literal>.</para> - <para>The default value for this parameter is <literal>true</literal>.</para> - <para>For more information on core bridges and how to configure them, please see - <xref linkend="core-bridges" />.</para> + <title>桥与重复检测</title> + <para>核心桥可以通过配置在将消息发向目的服务器之前自动向消息中添加唯一的id（如果消息中还没有的话）。这样 + 如果目的服务器发生故障，核心桥在重新发送消息时，目的服务器就可以自动检测重复的消息，发现重复消息即丢弃。</para> + <para>要配置核心桥的自动添加id的功能，需要在<literal>hornetq-configuration.xml</literal>中桥的配置 + 里将<parameter>use-duplicate-detection</parameter>参数设为<literal>true</literal>。</para> + <para>这个参数的默认值是<literal>true</literal>。</para> + <para>关于核心桥的配置和使用，参见<xref linkend="core-bridges" />。</para> </section> <section> - <title>Duplicate Detection and Cluster Connections</title> - <para>Cluster connections internally use core bridges to move messages reliable between - nodes of the cluster. Consequently they can also be configured to insert the duplicate - id header for each message they move using their internal bridges.</para> - <para>To configure a cluster connection to add the duplicate id header, simply set the - <parameter>use-duplicate-detection</parameter> to <literal>true</literal> when - configuring a cluster connection in <literal>hornetq-configuration.xml</literal>.</para> - <para>The default value for this parameter is <literal>true</literal>.</para> - <para>For more information on cluster connections and how to configure them, please see <xref - linkend="clusters"/>.</para> + <title>重复检测与集群连接</title> + <para>集群连接内部使用核心桥在节点间可靠地移动消息，因此它们的核心桥也可以配置自动添加id的功能。</para> + <para>配置的方法是在<literal>hornetq-configuration.xml</literal>文件中将集群连接的 + <parameter>use-duplicate-detection</parameter>参数设为<literal>true</literal>。</para> + <para>这个参数的默认值是<literal>true</literal>。</para> + <para>有关集群连接配置的更多信息，请参见<xref linkend="clusters"/>。</para> </section> <section> - <title>Duplicate Detection and Paging</title> - <para>HornetQ also uses duplicate detection when paging messages to storage. This is - so when a message is depaged from storage and server failure occurs, we do not end up - depaging the message more than once which could result in duplicate delivery.</para> - <para>For more information on paging and how to configure it, please see <xref - linkend="paging" />.</para> + <title>分页转存与重复检测</title> + <para>HornetQ在将消息进行分页转存中也使用了重复检测。当分页转存消息被从磁盘中读回到内存时，如果服务器发生故障， + 重复检测可以避免在这一过程中有消息被重复读入，即避免了消息的重复传递。</para> + <para>关于分页转存的配置信息请参见<xref linkend="paging" />。</para> </section> </chapter>