docs: remove extra ")" in index.md (apache#161)

content/zh/docs/overview/index.md

@@ -94,7 +94,7 @@ brpc特别重视开发和维护效率, 你可以通过浏览器或curl[查看ser
 
 - 对不同客户端请求的读取和解析是完全并发的，用户也不用区分”IO线程“和”处理线程"。其他实现往往会区分“IO线程”和“处理线程”，并把[fd](http://en.wikipedia.org/wiki/File_descriptor)（对应一个客户端）散列到IO线程中去。当一个IO线程在读取其中的fd时，同一个线程中的fd都无法得到处理。当一些解析变慢时，比如特别大的protobuf message，同一个IO线程中的其他fd都遭殃了。虽然不同IO线程间的fd是并发的，但你不太可能开太多IO线程，因为这类线程的事情很少，大部分时候都是闲着的。如果有10个IO线程，一个fd能影响到的”其他fd“仍有相当大的比例（10个即10%，而工业级在线检索要求99.99%以上的可用性）。这个问题在fd没有均匀地分布在IO线程中，或在多租户(multi-tenancy)环境中会更加恶化。在brpc中，对不同fd的读取是完全并发的，对同一个fd中不同消息的解析也是并发的。解析一个特别大的protobuf message不会影响同一个客户端的其他消息，更不用提其他客户端的消息了。更多细节看[这里](../rpc-in-depth/io/#收消息)。
 - 对同一fd和不同fd的写出是高度并发的。当多个线程都要对一个fd写出时（常见于单连接），第一个线程会直接在原线程写出，其他线程会以[wait-free](http://en.wikipedia.org/wiki/Non-blocking_algorithm#Wait-freedom)的方式托付自己的写请求，多个线程在高度竞争下仍可以在1秒内对同一个fd写入500万个16字节的消息。更多细节看[这里](../rpc-in-depth/io/#发消息)。
-- 尽量少的锁。高QPS服务可以充分利用一台机器的CPU。比如为处理请求[创建bthread](../rpc-in-depth/memory-management/), [设置超时](../rpc-in-depth/timer-keeping/), 根据回复[找到RPC上下文](../rpc-in-depth/bthread_id/), [记录性能计数器](../bvar/bvar/)都是高度并发的。即使服务的QPS超过50万，用户也很少在[contention profiler](../builtin-services/contention_profiler/))中看到框架造成的锁竞争。
+- 尽量少的锁。高QPS服务可以充分利用一台机器的CPU。比如为处理请求[创建bthread](../rpc-in-depth/memory-management/), [设置超时](../rpc-in-depth/timer-keeping/), 根据回复[找到RPC上下文](../rpc-in-depth/bthread_id/), [记录性能计数器](../bvar/bvar/)都是高度并发的。即使服务的QPS超过50万，用户也很少在[contention profiler](../builtin-services/contention_profiler/)中看到框架造成的锁竞争。
 - 服务器线程数自动调节。传统的服务器需要根据下游延时的调整自身的线程数，否则吞吐可能会受影响。在brpc中，每个请求均运行在新建立的[bthread](../bthread/bthread/)中，请求结束后线程就结束了，所以天然会根据负载自动调节线程数。
 
 brpc和其他实现的性能对比见[这里](../benchmark/)。