Add chinese translation docs. (#5224)

docs/zh_CN/shared-backend/DESIGN.md

@@ -0,0 +1,141 @@
+介绍 [![Slack](https://slack.minio.io/slack?type=svg)](https://slack.minio.io)
+------------
+
+该特性可以让多个Minio实例使用一个共享的NAS存储，而且不需要做什么特殊的设置。文件默认已经做了同步以及加锁。
+
+目的
+----------
+
+由于Minio的设计理念是为单租户场景服务，所以用户希望采用在一个存储后端上运行多个Minio实例，这个存储后端可能是一个已有的NAS。Minio支持这种共享存储后端的特性，而且不需要用户做额外的设置。
+
+
+限制
+------------
+
+* 如果正在执行GetObject()，则PutObject()会阻塞并等待。
+* 如果正在执行PutObject()或者GetObject()，则CompleteMultipartUpload()会阻塞并等待。
+* 无法
+* A CompleteMultipartUpload() is blocked and waits if another PutObject() or GetObject() is in progress.
+* 无法运行FS模式作为remote disk RPC。
+
+## 如何运行?
+
+运行共享存储后端的Minio和直接运行在一块独立磁盘的Minio没有啥区别，不需要做额外设置来开启这个特性。访问NAS上的文件默认就会加锁和同步。以下示例将对您选择的每个操作系统上的操作进行阐述：
+
+### Ubuntu 16.04 LTS
+
+示例1: 运行Minio实例在持载在`/path/to/nfs-volume`路径下的共享后端存储。
+
+On linux server1
+```shell
+minio server /path/to/nfs-volume
+```
+
+On linux server2
+```shell
+minio server /path/to/nfs-volume
+```
+
+### Windows 2012 Server
+
+示例1: 运行Minio实例在持载在`\\remote-server\cifs`路径下的共享后端存储。 
+
+On windows server1
+```cmd
+minio.exe server \\remote-server\cifs\data
+```
+
+On windows server2
+```cmd
+minio.exe server \\remote-server\cifs\data
+```
+
+或者共享存储挂载在`D:\`盘.
+
+On windows server1
+```cmd
+minio.exe server D:\data
+```
+
+On windows server2
+```cmd
+minio.exe server D:\data
+```
+
+架构
+------------------
+
+## POSIX/Win32 Locks
+
+### Lock process
+
+在同一个Minio实例中，lock由现有的内存命名空间锁（** sync.RWMutex **等）处理。 为了在许多Minio实例之间同步锁，我们利用Unix上的POSIX`fcntl（）`锁定和Windows`LockFileEx（）`Win32 API）。 如果相邻Minio实例在同一路径上有任何读锁，则写锁请求会被阻塞。 如果有正在进行的写锁，读锁也是如此。
+
+### Unlock process
+
+
+关闭文件描述符（fd）就会将之前获得的锁释放。关闭fd将告诉内核放弃当前进程在路径上保留的所有锁。当相同进程在同一路径上有多个读操作时，这会变得更加棘手，这意味着关闭一个fd也会为所有并发读释放锁。 为了正确地处理这种情况，实现了简单的fd引用计数，多个读操作之间共享相同的fd。 当读操作开始关闭fd时，我们开始减少引用计数，一旦引用计数达到零，我们可以确保没有更多的活跃读操作。 所以我们继续关闭底层文件描述符，这将放弃在路径上保留的读锁。
+
+这个不适用于写操作，因为对于每个对象总是有一个写和多个读。
+
+## 处理并发。
+
+这里的一个例子显示了如何使用GetObject()处理争用。
+
+GetObject()持有`fs.json`的一个读锁。
+
+```go
+	fsMetaPath := pathJoin(fs.fsPath, minioMetaBucket, bucketMetaPrefix, bucket, object, fsMetaJSONFile)
+	rlk, err := fs.rwPool.Open(fsMetaPath)
+	if err != nil {
+		return toObjectErr(traceError(err), bucket, object)
+	}
+	defer rlk.Close()
+
+... you can perform other operations here ...
+
+	_, err = io.CopyBuffer(writer, reader, buf)
+
+... after successful copy operation unlocks the read lock ...
+```
+
+对同一个对象的并发PutObject操作
+在同一个对象上请求一个并发的PutObject, PutObject()尝试获取一个`fs.json`上的写锁。
+
+```go
+	fsMetaPath := pathJoin(fs.fsPath, minioMetaBucket, bucketMetaPrefix, bucket, object, fsMetaJSONFile)
+	wlk, err := fs.rwPool.Create(fsMetaPath)
+	if err != nil {
+		return ObjectInfo{}, toObjectErr(err, bucket, object)
+	}
+	// This close will allow for locks to be synchronized on `fs.json`.
+	defer wlk.Close()
+```
+
+现在从上面的代码片段可以看到，直到GetObject()返回。 以下部分代码将被阻塞。
+
+```go
+	wlk, err := fs.rwPool.Create(fsMetaPath)
+```
+
+这咱限制是必须的，以避免给客户端返回损坏的数据。反之亦然，PutObject(),GetObject()也会等待PutObject()完成之后再执行。
+
+### 警告 (并发)
+
+假设有3个Minio服务共享一个存储后端
+
+minio1
+
+- DeleteObject(object1) --> 在object1删除操作时持有`fs.json`的锁。
+
+minio2
+
+- PutObject(object1) --> 等DeleteObject完毕后进行锁定。
+
+minio3
+
+- PutObject(object1) --> (concurrent request during PutObject minio2 checking if `fs.json` exists)
+
+一旦获取到锁之后，minio2验证文件是否真的存在，以避免获得已被删除的fd的锁。但是这种情况与minio3存在竞争，因为minio3也在尝试写同一个文件。这就存在一种可能，`fs.json`已经被创建了，所以minio2获得的锁就无效，这样就可能会导致数据不一致。
+
+这是一种已知的问题，而且没办法通过POSIX fcntl锁来解决。这种情况是共享存储后端的限制，请你知晓。

docs/zh_CN/shared-backend/README.md

@@ -0,0 +1,71 @@
+# Minio共享后端存储快速入门[![Slack](https://slack.minio.io/slack?type=svg)](https://slack.minio.io) [![Go Report Card](https://goreportcard.com/badge/minio/minio)](https://goreportcard.com/report/minio/minio) [![Docker Pulls](https://img.shields.io/docker/pulls/minio/minio.svg?maxAge=604800)](https://hub.docker.com/r/minio/minio/) [![codecov](https://codecov.io/gh/minio/minio/branch/master/graph/badge.svg)](https://codecov.io/gh/minio/minio)
+
+Minio共享模式可以让你使用一个[NAS](https://en.wikipedia.org/wiki/Network-attached_storage) 做为多个Minio服务的存储后端。我我们在设计时已经对多个Minio服务之间的同步做了很多的处理。更多Minio共享模式的设计文档，请访问[这里](https://github.com/minio/minio/blob/master/docs/shared-backend/DESIGN.md).
+
+Minio共享模式是为了解决在真实场景中存在的一些问题，而且不需要做额外的配置。
+如果你有下列需求，则可以考虑Minio共享模式
+
+- 你已经买了NAS设备，并想在存储层使用Minio来增加S3兼容。
+- 你的应用架构要求你使用带有S3接口的NAS。
+- 你的应用存在亚历山大的流量，你想给你的NAS设备增加一个有负载均衡能力的S3兼容的服务。 
+
+在多个共享模式的Minio服务前面加一层代理，你很容易就能获得一个高可用，负载均衡，AWS S3兼容的存储系统。
+
+# 开始
+
+如果你知道怎么部署单机Minio,共享模式的部署和运行也是一样一样的。
+
+## 1. 前提条件
+
+安装Minio - [Minio快速入门](https://docs.minio.io/docs/zh_CN/minio).
+
+## 2. 在共享后端存储上运行Minio
+
+为了让Minio在共享后端上运行起来，你需要启动多个Minio服务，这些服务指向同一个后端存储。下面我们就来讲解如何设置。
+
+*注意*
+
+- 使用共享存储的所有Minio节点需要有相同的access key和secret key。为了做到这一点，我们在所有节点上将access key和secret key export成环境变量，然后再去启动Minio服务。
+- 下面出现的存储路径都是为了演示目的，在真实环境中使用时，你应该替换成你真实要用的路径。
+
+#### Minio shared mode on Ubuntu 16.04 LTS. 
+
+你需要将文件夹指向共享存储，比如`/path/to/nfs-volume`，然后在所有Minio节点上运行下面的命令。
+
+```sh
+export MINIO_ACCESS_KEY=<ACCESS_KEY>
+export MINIO_SECRET_KEY=<SECRET_KEY>
+minio server /path/to/nfs-volume
+```
+
+#### Minio shared mode on Windows 2012 Server
+
+你需要将文件夹指向共享存储，比如`\\remote-server\smb`. 然后在所有Minio节点上运行下面的命令。
+
+```cmd
+set MINIO_ACCESS_KEY=my-username
+set MINIO_SECRET_KEY=my-password
+minio.exe server \\remote-server\smb\export
+```
+
+*Windows提示*
+
+如果一个远程的volume, 比如`\\remote-server\smb`挂载成一个硬盘, 比如`M:\`. 你可以使用[`net use`](https://technet.microsoft.com/en-us/library/bb490717.aspx)命令将这块盘映射到一个文件夹。
+
+```cmd
+set MINIO_ACCESS_KEY=my-username
+set MINIO_SECRET_KEY=my-password
+net use m: \\remote-server\smb\export /P:Yes
+minio.exe server M:\export
+```
+
+## 3. 验证
+
+为了验证部署是否成功，可能通过浏览器或者[`mc`](https://docs.minio.io/docs/zh_CN/minio-client-quickstart-guide)访问Minio。你应该可以从各个Minio节点访问上传的文件。
+
+## 了解更多
+- [使用`mc`](https://docs.minio.io/docs/zh_CN/minio-client-quickstart-guide)
+- [使用`aws-cli`](https://docs.minio.io/docs/zh_CN/aws-cli-with-minio)
+- [使用`s3cmd`](https://docs.minio.io/docs/zh_CN/s3cmd-with-minio)
+- [使用`minio-go` SDK](https://docs.minio.io/docs/zh_CN/golang-client-quickstart-guide)
+- [Minio文档](https://docs.minio.io)