diff --git a/Solution.md b/Solution.md
index 62a40ef..7b15ee7 100644
--- a/Solution.md
+++ b/Solution.md
@@ -2668,7 +2668,7 @@ public class DistributedLockDemo {
 
 ### TPS
 
-**系统吞吐量是衡量系统性能的关键指标，按照事务的完成数量来限流是最合理的。**
+**TPS（Transactions Per Second）是指每秒事务数**。一个事务是指事务内第一个请求发送到接收到最后一个请求的响应的过程，以此来计算使用的时间和完成的事务个数。
 
 > 但是对实操性来说，按照事务来限流并不现实。在分布式系统中完成一笔事务需要多个系统的配合。比如我们在电商系统购物，需要订单、库存、账户、支付等多个服务配合完成，有的服务需要异步返回，这样完成一笔事务花费的时间可能会很长。如果按照TPS来进行限流，时间粒度可能会很大大，很难准确评估系统的响应性能。
 
@@ -2678,7 +2678,7 @@ public class DistributedLockDemo {
 
 ### HPS
 
-**每秒请求数，指每秒钟服务端收到客户端的请求数量。**
+ **HPS（Hits Per Second）指每秒点击次数（每秒钟服务端收到客户端的请求数量）**。是指在一秒钟的时间内用户对Web页面的链接、提交按钮等点击总和。 它一般和TPS成正比关系，是B/S系统中非常重要的性能指标之一。
 
 > 如果一个请求完成一笔事务，那TPS和HPS是等同的。但在分布式场景下，完成一笔事务可能需要多次请求，所以TPS和HPS指标不能等同看待。
 
@@ -2688,7 +2688,7 @@ public class DistributedLockDemo {
 
 ### QPS
 
-**服务端每秒能够响应的客户端查询请求数量。**
+**QPS（Queries Per Second）是指每秒查询率**。是一台服务器每秒能够响应的查询次数（数据库中的每秒执行查询sql的次数），显然这个不够全面，不能描述增删改，所以不建议用QPS来作为系统性能指标。
 
 > 如果后台只有一台服务器，那 HPS 和 QPS 是等同的。但是在分布式场景下，每个请求需要多个服务器配合完成响应。