常用的maven仓库：
1. nexus 2.*版本主要针对maven仓库，3.*版本功能比较强大，详细区别查官网；nexus-repository-oss 免费
2. artifactory 功能强大，提供丰富的rest 接口，如果需要devops可以考虑使用；收费
我们公司现在使用的是nexus-repository-oss 2.*
随着公司项目组的使用量增加，为了防止nexus奔溃，准备搭建nexus的集群:
需要解决的问题：
仓库类资源需要同步，即一个jar包传到一台nexus服务器，集群里面其他的服务器需要能够立马获取到该jar包
解决方案有很多：
1. 集群之间使用一个共享存储，例如我们就是采用挂载一块nas盘的方案
2. 通过资源实时同步的方案，例如采用 rsync + inotify实现服务器之间文件实时同步
我采用的是第一种方案，第二种感觉比较麻烦，需要我自己干的事情比较多，不过个人认为第二种才是最佳的集群的方式，支持并发什么的，io瓶颈都会比第一种好，待有时间再试一试
先介绍第一种方案中的坑
我服务器A与B 上挂载了同一块nas盘到我的 /nasfiles/sonatype-work/nexus 目录
服务器A 上安装 nexus，目录结构如下：
进入conf目录，修改 nexus.properties
将 nexus-work目录指向我们的nas盘所挂载的目录
启动服务器A的nexus服务，
cd ../bin
./nexus start
启动之后，访问我们的nexus， http://ip:port/nexus 我的port改成了8080 默认为8081；nexus start显示启动成功之后，页面需要一小会才能访问
启动成功的页面如下：
查看repositories，默认的只有 中央仓库和 apatch的仓库，这里可以自己添加一些常用的代理仓库，我添加了aliyun的作为代理仓库，另外新建了几个hosted的仓库用于不同开发部存放二方库的包
到这里都很简单，很流畅的完成；
后面是我们的重点，搭建服务器B的nexus；
因为需要共享仓库的资源，所以我也是按照服务器A的方式去修改nexus.properties，地址也是指向的nas盘所在目录，即配置
nexus-work=/nasfiles/sonatype-work/nexus
同样启动 nexus start；
直接启动报错，错误原因很简单，当前目录已经被使用（英文报错信息翻译过来就这意思）
到/nasfiles/sonatype-work/nexus里面瞄了一下：
这是nexus实际运行时的工作目录，一眼就看到了nexus.lock这个文件，果断打开看一下：
一个id + 服务器名称
id就是 nexus服务运行的pid， ps -ef|grep nexus 就可以看到我的nexus服务的pid就是18381
仔细想想，也要道理，nexus采用这种lock的检查方式，防止同时有多个服务去操作nexus中的配置；也是为了防止出现文件冲突吧
不管什么原因了，反正我现在想搭集群，那就解决这个吧；当然 如果采用 服务器同步的话 ，就没有这种目录已经被使用的问题啦，毕竟不是使用的同一个目录
继续尝试，
既然我们不能使用/nasfiles/sonatype-work/nexus 作为我的工作目录，那就改一个地址吧，先把nexus.properties还原回去
还是 使用默认的工作目录吧，先启动看看，没啥问题，正常启动，看看我们的${bundleBasedir}/../sonatype-work/nexus目录下，和/nasfiles/sonatype-work/nexus是一样的，
那就解决我们的资源共享问题吧，首先整理一下，我们的资源在那里，瞄了一下，可以发现
conf 目录：
主要的配置文件就是nexus.xml，打开一看，里面全部都是我nexus页面上配置的 repositories的信息，repositoryGrouping的信息以及配置的一些tasks
indexer目录：看名字也知道是索引文件
storage目录：我的仓库的信息，这个也是最重要的资源存放的地址，jar包，war包什么的都在这里啦
那么问题来了，我只需要将storage共享了，问题不就解决了吗，那我直接将我的nas盘挂载到 服务器A 和B的 /nasfiles/sonatype-work/nexus/storage目录，
资源就可以共享了吗，/nasfiles/sonatype-work/nexus目录下其他的文件和文件夹在服务器A和服务器B是独立的，互补干扰，启动也就没什么问题啦，这个方式应该可行；
可惜，我们的nas盘上面都已经存放的jar和war都已经几十个G啦，提工单又要找公司系统组的人处理，算啦；换个方式，
尝试服务器B上采用软链接的方式吧，测试一下，将服务器B的nexus工作目录下的storage目录删除掉，然后采用软链接
ln -s /nasfiles/sonatype-work/nexus/storage ./storage
这样我服务器B的当前工作目录就成了以下情况：
尝试重启服务器B的服务； nexus restart
启动成功，
为了测试一下效果，先在服务器A上面，下载一些jar包下来，下载jar的方式，本地随便搞一个maven项目，pom.xml中配置一下服务器A的仓库地址，一般直接使用public Repositories这个group组 后面的那个url 就可以啦；或者本地settings.xml配置一下
<mirrors>
<mirror>
<id>all</id>
<mirrorOf>*</mirrorOf>
<url>http://10.191.9.13:8080/nexus/content/groups/public/</url>
</mirror>
</mirrors>
然后mvn install跑一下本地项目，先让服务器A的nexus下载一些jar包
确保服务器A的nexus已经下载了一些jar之后；我们到服务器B的nexus页面上看一眼，会发现服务器A中央仓库中；已经有jar包了，说明我们服务器A的包已经可以在服务器B展现啦；
结束啦，其实没有；
有没有发现服务器B的页面Repositories里面没有我们的在服务器A的nexus页面自己创建的仓库；同样的我们试一下手动传一些jar包到我们的服务器A的自己创建的hosted的仓库上；
分别打开http://服务器A的ip:8080/nexus/content/groups/public/ 和 http://服务器B的ip:8080/nexus/content/groups/public/ 找一下刚刚上传的jar的位置，会发现A上面有些包在B上不显示，下载也不行；
原因就是因为B上面没有配置过这些仓库，B的public repo的group里面就没有这些库；
继续修改，将A的nexus.xml的内容复制一份到B的nexus.xml里面；
nexus.xml中 的 repositoryTargets repositoryGrouping repositories memberRepositories 标签里面的内容需要保持一致
tasks标签 B节点最好不要
这样从B下载A上面所有的包就不存在问题啦；
至于负载均衡，这个就自己找nginx配置啦，或者我们是直接弄个F5，配置一下负载，问题就搞定啦
我弄的比较简单，配置一下，凡是nexus/content/groups/public开头的，进行负载；非nexus/content/groups/public开头的，全部到A上面，这样用户使用搜索时，请求都是直接到A的，而A上面索引都是全的；
仅仅下载资源会同时用于A和B；
