diff --git a/docs/content/about/license.md b/docs/content/about/license.md
index 48070d9..b26942f 100644
--- a/docs/content/about/license.md
+++ b/docs/content/about/license.md
@@ -2,7 +2,7 @@
 
 **MIT License**
 
-Copyright (c) 2016 - 2019 Saborboard
+Copyright (c) 2016 - 2019 Savorboard
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
diff --git a/docs/content/about/release-notes.md b/docs/content/about/release-notes.md
index 2b0a841..d5ef6e8 100644
--- a/docs/content/about/release-notes.md
+++ b/docs/content/about/release-notes.md
@@ -1,5 +1,24 @@
 # Release Notes
 
+## Version 2.5.1 (2019-06-21)
+
+**Features:**
+
+* Improved logs record.
+* Upgrade dependent nuget packages version. (MySqlConnector, confluent-kafka-dotnet-1.0 )
+* NodeId type change to string of DiscoveryOptions for Consul. (#314)
+* Change the IConsumerServiceSelector interface access modifier to public. (#333)
+* Improved RabbitMQOptions to provide extensions option to configure the client original configuration. (#350)
+* Add index for MongoDB CAP collections. (#353)
+
+**Bugs Fixed:**
+
+* Fixed consumer re-register transport bug. (#329)
+* Handle messages retrieval failure. (#324)
+* Fixed DiagnosticListener  null reference exception bug. (#335)
+* Add subscription name validation for the AzureServerBus. (#344)
+* Fixed thread safety issues of publisher. (#331)
+
 ## Version 2.5.0 (2019-03-30)
 
 **Features:**
diff --git a/docs/content/user-guide/zh/cap/idempotence.md b/docs/content/user-guide/zh/cap/idempotence.md
index 7ba46fd..e2e9bc9 100644
--- a/docs/content/user-guide/zh/cap/idempotence.md
+++ b/docs/content/user-guide/zh/cap/idempotence.md
@@ -1,12 +1,12 @@
-# Idempotence
+# 幂等性
 
-幂等性（你可以在[Wikipedia](https://en.wikipedia.org/wiki/Idempotence)读到关于幂等性的定义），当我们谈论幂等时，一般是指可以重复处理传毒的消息，而不是产生意外的结果。
+幂等性（你可以在[Wikipedia](https://en.wikipedia.org/wiki/Idempotence)读到关于幂等性的定义），当我们谈论幂等时，一般是指可以重复处理传递的消息，而不会产生意外的结果。
 
 ## 交付保证
 
 在说幂等性之前，我们先来说下关于消费端的消息交付。
 
-由于CAP不是使用的 MS DTC 或其他类型的2PC分布式事务机制，所以存在至少消息严格交付一次的问题，具体的说在基于消息的系统中，存在一下三种可能：
+由于CAP不是使用的 MS DTC 或其他类型的2PC分布式事务机制，所以存在至少消息严格交付一次的问题，具体的说在基于消息的系统中，存在以下三种可能：
 
 * Exactly Once(*) （仅有一次）
 * At Most Once （最多一次）