推 荐 游 戏
您当前的位置：
德州扑克新手需注意的一些问题时间： 10:04:00 来源：聚侠网 作者：
《德州扑克》是一款很不错的游戏，在上市之前已经受到了广泛的关注，现在公测已经很久了，小编就来谈一谈一些玩法的问题吧，希望能对您有所帮助！
部分初学者只是紧盯自己的牌，却不注意观察对手的举动。所谓牌的大小，只有和对手比才有实际意义。三条是副大牌，但只有在对手没有顺子和同花时才能获胜。所以，时刻关注对手举动，判断其牌力很重要。
如果一个打牌风格较紧且保守的玩家加注，意味着很大的牌；而一个又松又猛，甚至疯狂的玩家加注，则未必如此了。解决办法：应当时刻关注对手的下注行为和打牌风格。
如果遵照APA的起手牌表，80%的时候你都未参与到牌局当中，这时你的任务是关注对手如下举动：对手是很松的玩家吗？那么他会玩很多起手牌，并有很多不合理的跟注。
对手很紧吗？那他只打好的起手牌，并在翻牌后，只有较大牌时才跟。对手保守（多数时候只是观望-跟注）吗？还是牌风较猛（喜欢主动下注或加注）？
诈牌（即明知牌力落后仍下注或加注，逼对手弃牌）是扑克游戏的一部分，但很多玩家不懂得正确的诈牌时机，往往在胜算很低时出手诈牌。当面对3个或以上的对手时，诈牌很少是正确的。对手越多，诈牌成功的可能性越低。只有在判断所有对手都会弃牌的时候，才能诈牌。
有一个重要的事实是，低限注玩家的主要错误是跟注太多，因此你很少能逼使他们弃牌。在低限注游戏中，诈牌很难获得成功。作为初学者，你击败对手主要依靠的是良好的纪律性和对牌局的正确判断。
很多人刚进入牌桌，未轮到下盲注时，会在任何位置花相当于一个大盲注的代价，买座进入牌局。从长期讲，这会使你输钱。
等到大盲注位置时再投注，或最多在Cutoff位置（庄家紧右边、倒数第二个后位置）买座进入，坐在比这靠前的位置时，就等盲注。不要急于进入牌局，在软件功能选择上，总选上wait for the big blind（等待大盲注）。
好了，对这篇攻略的解析就是这些了，希望可能对你有帮助，更多游戏攻略，敬请关注聚侠网，聚侠网将会是您游戏的忠实伴侣！
相关新闻专题推荐{"debug":false,"apiRoot":"","paySDK":"/api/js","wechatConfigAPI":"/api/wechat/jssdkconfig","name":"production","instance":"column","tokens":{"X-XSRF-TOKEN":null,"X-UDID":null,"Authorization":"oauth c3cef7c66aa9e6a1e3160e20"}}
{"database":{"Post":{"":{"contributes":[{"sourceColumn":{"lastUpdated":,"description":"","permission":"COLUMN_PUBLIC","memberId":,"contributePermission":"COLUMN_PUBLIC","translatedCommentPermission":"all","canManage":true,"intro":"汇集阿里技术精粹-","urlToken":"yunqichengxuyuan","id":29437,"imagePath":"v2-f41c4ececa862f50bdaa851db41c3f54.jpg","slug":"yunqichengxuyuan","applyReason":"0","name":"我是程序员","title":"我是程序员","url":"/yunqichengxuyuan","commentPermission":"COLUMN_ALL_CAN_COMMENT","canPost":true,"created":,"state":"COLUMN_NORMAL","followers":9458,"avatar":{"id":"v2-f41c4ececa862f50bdaa851db41c3f54","template":"/{id}_{size}.jpg"},"activateAuthorRequested":false,"following":false,"imageUrl":"/v2-f41c4ececa862f50bdaa851db41c3f54_l.jpg","articlesCount":315},"state":"accepted","targetPost":{"titleImage":"/v2-af23d550ee9fa2c30c528b0c51150c21_r.jpg","lastUpdated":,"imagePath":"v2-af23d550ee9fa2c30c528b0c51150c21.jpg","permission":"ARTICLE_PUBLIC","topics":[707,],"summary":"4月10日上午11点多，人工智能“冷扑大师”在与中“国龙之队”的六位德扑高手连续比了四天半后，人类选手再次完败。这篇人工智能的热点新闻也是一时间刷屏。小编也来凑凑热闹，不过作为一个维护世界和平的程序员，不能只做一个吃瓜群众。分享一篇德州扑克的…","copyPermission":"ARTICLE_COPYABLE","translatedCommentPermission":"all","likes":0,"origAuthorId":0,"publishedTime":"T11:43:47+08:00","sourceUrl":"","urlToken":,"id":2704272,"withContent":false,"slug":,"bigTitleImage":false,"title":"分享一个德州扑克的：最大牌型，比牌逻辑的算法和洗牌的方法","url":"/p/","commentPermission":"ARTICLE_ALL_CAN_COMMENT","snapshotUrl":"","created":,"comments":0,"columnId":29437,"content":"","parentId":0,"state":"ARTICLE_PUBLISHED","imageUrl":"/v2-af23d550ee9fa2c30c528b0c51150c21_r.jpg","author":{"bio":"汇集阿里技术精粹，","isFollowing":false,"hash":"65b52731faea3de2ef3fffa1","uid":282900,"isOrg":true,"slug":"a-li-yun-yun-qi-she-qu-48","isFollowed":false,"description":"“云栖社区”是阿里云官方开发者技术社区，聚焦于传播云计算、大数据等DT时代核心技术的内容与资源。","name":"阿里云云栖社区","profileUrl":"/org/a-li-yun-yun-qi-she-qu-48","avatar":{"id":"v2-8f5f8eefcb27de64ffbefee","template":"/{id}_{size}.jpg"},"isOrgWhiteList":true},"memberId":,"excerptTitle":"","voteType":"ARTICLE_VOTE_CLEAR"},"id":609522}],"title":"分享一个德州扑克的：最大牌型，比牌逻辑的算法和洗牌的方法","author":"a-li-yun-yun-qi-she-qu-48","content":"4月10日上午11点多，人工智能“冷扑大师”在与中“国龙之队”的六位德扑高手连续比了四天半后，人类选手再次完败。这篇人工智能的热点新闻也是一时间刷屏。小编也来凑凑热闹，不过作为一个维护世界和平的程序员，不能只做一个吃瓜群众。分享一篇德州扑克的算法内容给大家练练手，没准下一次的打败人类AI程序员就是你哦：（本文由云栖社区： 提供）德州扑克想必很多人都玩过，当然对于新手需要说明的是，德州指的是德克萨斯州，而不是山东德州。
这几个月一直在做一个德州扑克的服务器，分享下在计算最大牌型，比牌逻辑的算法和洗牌的方法，希望对大家有帮助。
首先我们定义一下Poker类public class Poker\n{\n
private S // 图片扑克花色的表示（代表的是红桃、黑桃,梅花、方块\ // 表示扑克牌面的大\n \n
public Poker(String tag, int num)\n
this.num =\n
this.tag =\n
public int getNum()\n
public void setNum(int num)\n
this.num =\n
public void setTag(String tag)\n
this.tag =\n
public String getTag()\n
public String toString()\n
return \" tag: \" + this.tag +\" num: \" + this.\n
\n}\n　　这里说明下，ABCD代表四种不同的花色，2-16代表不同的牌面，A用14代替，我想不用多解释吧！　　首先是洗牌这块，我们奔着不重复造轮子的思想，借用Collections.shuffle(List)接口，去将52张牌打乱顺序，然后随机随机抽取。
首先是，获取每个玩家的最大牌型，即从N张扑克中取出5张最大的，我们从N张牌中抽出5张牌，有N多种算法，这里给出一个算法private static Map&Integer, List&Poker&& SevenToFiveGroups(List&Poker& map)\n
Map&Integer, List&Poker&& group = new HashMap&Integer, List&Poker&&();\n
int num = 0;\n
for (int a = 0; a & 3; a++)\n
for (int b = a + 1; b & 4; b++)\n
for (int c = b + 1; c & 5; c++)\n
for (int d = c + 1; d & 6; d++)\n
for (int e = d + 1; e & 7; e++)\n
List&Poker& pukeGroup = new ArrayList&Poker&();\n
pukeGroup.add(map.get(a));\n
pukeGroup.add(map.get(b));\n
pukeGroup.add(map.get(c));\n
pukeGroup.add(map.get(d));\n
pukeGroup.add(map.get(e));\n
group.put(num++, pukeGroup);\n
num = 0;\n\n
在取得所有可能的组合之后，我们从这些组合中得到最大的一副手牌。为了得到最大的一副手牌，我们计算每付(五张牌)手牌的大小。首先对这五张牌进行排序，从大到小，手牌的大小为一个Long整形的数，手牌等级占两位（比如高牌为10，一对为11，二两为12,以此类推），五张扑克，每张扑克的数值占两位，所以手牌的大小是一个12位的整数，　　比如图1.2的一副牌手牌等级第一张牌第二张牌第三张牌第四张牌第五张牌10A(A)U(B)10(C)9(D)7(C)
图1.2　　 这副手牌的大小为 　　需要注意的是，在遇到有对子的是情况，无论是两对还是三双，都要进行特殊排序，葫芦和三双的情况下，要把三个一样的大的牌排到前面，然后再排对子，这样才能保证在比较牌大小的情况下，正确比较出大小。还有就是在遇到A2345这样的顺子的情况下，要讲A排在最后，因为34567的顺子是比A2345大的。当然这两种情况是属于比较特殊情况，需要特别处理。对应程序的算法为：　　首先计算手牌的等级，如果是顺子或者同花就不用说了，对子三双葫芦起始是相对比较难比较的，这里给出一个算法，int Pukelevel = -1;\n
int flag = 0;\n
for (int i = 0; i & list.size(); i++)\n
for (int j = i + 1; j & list.size(); j++)\n
if (list.get(i).getNum() == list.get(j).getNum())\n
switch (flag)\n
this.level即牌型， 就是这样计算出来的，然后就是计算这副手牌的大小了！long lon = L * 10;\n
this.pkValue = 0L;\n
for(int i = 0 ; i & this.list.size() ; i++)\n
int interval = 1;\n
for(int j = j & this.list.size() - 1 ; j ++)\n
interval *= 10;\n
interval *= 10;\n
this.pkValue += this.list.get(i).getNum() *\n
this.pkValue += this.level *\n　　剩下的就是对所有的情况，进行排序；所有玩家比较的时候，也是这样的情况！
希望对大家有帮助。更多技术干货，请关注：","updated":"T03:43:47.000Z","canComment":false,"commentPermission":"anyone","commentCount":3,"collapsedCount":0,"likeCount":15,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-af23d550ee9fa2c30c528b0c51150c21_r.jpg","links":{"comments":"/api/posts//comments"},"reviewers":[],"topics":[{"url":"/topic/","id":"","name":"程序员"},{"url":"/topic/","id":"","name":"编程学习"},{"url":"/topic/","id":"","name":"德州扑克"}],"adminClosedComment":false,"titleImageSize":{"width":600,"height":333},"href":"/api/posts/","excerptTitle":"","column":{"slug":"yunqichengxuyuan","name":"我是程序员"},"tipjarState":"inactivated","annotationAction":[],"sourceUrl":"","pageCommentsCount":3,"hasPublishingDraft":false,"snapshotUrl":"","publishedTime":"T11:43:47+08:00","url":"/p/","lastestLikers":[{"bio":null,"isFollowing":false,"hash":"abf641b4c101eeeaa5850df1","uid":422100,"isOrg":false,"slug":"li-zi-jie-17-44","isFollowed":false,"description":"","name":"李子杰","profileUrl":"/people/li-zi-jie-17-44","avatar":{"id":"71ba83c6a87c42d4413e","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"作曲","isFollowing":false,"hash":"c17ca9b848abbf","uid":306000,"isOrg":false,"slug":"pi-li-run","isFollowed":false,"description":"","name":"噼里run","profileUrl":"/people/pi-li-run","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"机关外勤","isFollowing":false,"hash":"01ea5bfc2ffedff8a119730","uid":235000,"isOrg":false,"slug":"dancematthiola","isFollowed":false,"description":"","name":"dancematthiola","profileUrl":"/people/dancematthiola","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":"计算机硬件技术","isFollowing":false,"hash":"1d285f1e181e436f9918","uid":971100,"isOrg":false,"slug":"eudorapeony","isFollowed":false,"description":"","name":"eudorapeony","profileUrl":"/people/eudorapeony","avatar":{"id":"da8e974dc","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false},{"bio":null,"isFollowing":false,"hash":"873b47cd6f11ab5a7d0c2601caa01ca1","uid":540700,"isOrg":false,"slug":"hu-bao-jun-34","isFollowed":false,"description":"","name":"守望星空","profileUrl":"/people/hu-bao-jun-34","avatar":{"id":"v2-836db6a190bceb2ec0f0","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false}],"summary":"4月10日上午11点多，人工智能“冷扑大师”在与中“国龙之队”的六位德扑高手连续比了四天半后，人类选手再次完败。这篇人工智能的热点新闻也是一时间刷屏。小编也来凑凑热闹，不过作为一个维护世界和平的程序员，不能只做一个吃瓜群众。分享一篇德州扑克的…","reviewingCommentsCount":0,"meta":{"previous":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-606cfd92e552d22ff37fc_r.jpg","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"阿里云"},{"url":"/topic/","id":"","name":"阿里巴巴集团"},{"url":"/topic/","id":"","name":"峰会"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"bio":"汇集阿里技术精粹，","isFollowing":false,"hash":"65b52731faea3de2ef3fffa1","uid":282900,"isOrg":true,"slug":"a-li-yun-yun-qi-she-qu-48","isFollowed":false,"description":"“云栖社区”是阿里云官方开发者技术社区，聚焦于传播云计算、大数据等DT时代核心技术的内容与资源。","name":"阿里云云栖社区","profileUrl":"/org/a-li-yun-yun-qi-she-qu-48","avatar":{"id":"v2-8f5f8eefcb27de64ffbefee","template":"/{id}_{size}.jpg"},"isOrgWhiteList":true},"column":{"slug":"yunqichengxuyuan","name":"我是程序员"},"content":"大会嘉宾：——————————————————————————————————会议日程：：9：00-9：10
致辞——特邀嘉宾 9：10-9：30
主题演讲：飞天·智能——胡晓明 阿里巴巴集团资深副总裁、阿里云总裁 9：30-9：40
重磅发布一9：40-9：50
重磅发布二9：50-10：00
重磅发布三10：00-10：20
主题演讲：工业互联网新时代——创新客户代表 10：20-10：40
主题演讲：大数据助力制造升级——创新客户代表 10：40-10：50
重磅发布四10：50-11：00
重磅发布五11：00-11：10
重磅发布六11：10-11：30
主题演讲：云数据 大计算——闵万里 阿里云人工智能科学家 ：13：30-14：15
企业级互联网架构(Aliware)实践——钟华 阿里中间件高级架构师 14：15-15：00
Aliware云产品领航2017——赵林 阿里中间件资深产品专家 15：00-15：30
DT时代企业智能转型路径及最佳实践——合作伙伴代表 15：30-16：00
新零售—业务中台和数据中台最佳实践——行业标杆客户 16：00-16：30
阿里云工业互联网与制造升级——行业标杆客户 16：30-17：00
混合云—企业上云的最佳实践——黄兵 阿里云企业业务事业部高级专家 ：13：30-14：00
新制造的核心竞争力----挖掘数据价值——敬请期待 14：00-14：30
新制造的实践路径----畅享数据红利——敬请期待 14：30-15：00
DT技术助推制造业智能转型——敬请期待 15：00-15：30
智能制造的众志成城----众智平台——敬请期待 15：30-16：00
阿里云1+30+300项目详解——敬请期待 16：00-17：00
对话：理论派、观望者和行动家——敬请期待 ——————————————————————————————————会议指南南京香格里拉酒店—南京·鼓楼区·中央路329号参会须知Q1、如何表示报名成功，参加大会的凭据是什么?A：报名成功后，会收到报名成功的短信。进入会场凭借二维码和本人身份证，二维码将在开会前3天左右发送到报名时的手机上。Q2、没有报名的人临时到会场当场报名可以吗? A：非常抱歉，因为会场安排的问题，暂时不支持临时报名。交通指南- 南京禄口国际机场，驾车距离40公里（约45分钟） - 南京火车站，驾车距离3.6公里（约8分钟）- 南京南站，驾车距离16公里（约38分钟）- 市中心，驾车距离4.4公里（约10分钟）- 地铁1号线新模范马路站，步行距离300米（约5分钟）住宿指南汉庭酒店(玄武门店)，步行距离300米（约5分钟） 桔子酒店(玄武门店)，步行距离300米（约5分钟）- 古都饭店，步行距离500米（约7分钟）- 南京玄武门亚朵酒店，步行距离600米（约10分钟）- 南京威斯汀大酒店，步行距离850米（约15分钟）- 玄武饭店，步行距离900米（约15分钟）餐饮指南除了附近的餐饮店外，以下购物广场和美食街均可用餐：三牌楼大街（打车5分钟） 金茂广场购物中心（金茂汇，步行10分钟）湖南路美食一条街（步行15分钟）地铁1号线至市中心新街口站（新模范马路-新街口，约15分钟）停车指南会议酒店停车场对外6元/小时，每天48元封顶。","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T10:32:48+08:00","url":"/p/","title":"飞天-智能：2017云栖大会-南京峰会免费报名中","summary":"大会嘉宾：—————————————————————————————————— 会议日程：：9：00-9：10 致辞——特邀嘉宾 9：10-9：30 主题演讲：飞天·智能——胡晓明 阿里巴巴集团资深副总裁、阿里云总裁 9：30-9：40 重磅发布…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":2,"likesCount":4},"next":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"阿里巴巴集团"},{"url":"/topic/","id":"","name":"程序员"},{"url":"/topic/","id":"","name":"代码托管"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"bio":"汇集阿里技术精粹，","isFollowing":false,"hash":"65b52731faea3de2ef3fffa1","uid":282900,"isOrg":true,"slug":"a-li-yun-yun-qi-she-qu-48","isFollowed":false,"description":"“云栖社区”是阿里云官方开发者技术社区，聚焦于传播云计算、大数据等DT时代核心技术的内容与资源。","name":"阿里云云栖社区","profileUrl":"/org/a-li-yun-yun-qi-she-qu-48","avatar":{"id":"v2-8f5f8eefcb27de64ffbefee","template":"/{id}_{size}.jpg"},"isOrgWhiteList":true},"column":{"slug":"yunqichengxuyuan","name":"我是程序员"},"content":"本文主要介绍了阿里巴巴集团代码服务团队，在过去一年基于GitLab进行的代码托管分布式改造，希望与大家进行分享与探讨，为云上开发者提供更好的代码托管服务。本文由： 提供一、背景介绍毋庸置疑，代码是DevOps流程的起点，是所有研发流程的基础；代码托管为代码“保驾护航”，确保代码的安全性、可用性，同时提供围绕代码的一些基础服务，如、等等。阿里巴巴集团GitLab是基于GitLab社区版8.3版本开发，目前支撑全集团数万规模的研发团队，累计创建数十万项目，日请求量千万级别，存储TB级别，早已超过了GitLab社区版承诺的单机上限能力，且增长速度迅猛。面对这种情况，顺理成章的做法就是——扩容。然而非常不幸，GitLab的设计没有遵守Heroku推崇的的第四条：“把后端服务当作附加资源”（即对应用程序而言，不管是数据库、消息队列还是缓存等，都应该是附加资源，通过一个url或是其他存储在配置中的服务定位来获取数据；部署应可以按需加载或卸载资源），具体体现是：Git仓库数据存储于服务器本地的文件系统之上GitLab所依赖的三个重要组件：libgit2、git、grit也都是直接操作在文件系统上GitLab所以GitLab社区版是基于“单机”模式设计，当存储容量和单机负载出现瓶颈时，难以扩容！二、面对挑战2015年初，阿里巴巴集团GitLab的单机负载开始呈现居高不下的情况，当时的应对方案是同步所有仓库信息到多台机器，将请求合理分配到几台机器上面从而降低单机的负载。然而这个方法治标不治本：系统运行过程中的数据同步消耗资源和时间，不可能无限制扩充机器这种方案暂时缓解了单机负载的问题，但对于单机存储上限的问题束手无策2015年中，团队正式启动了第一次改造尝试，当时的思路是去掉对本地文件系统的依赖，使用网络共享存储，具体思考和方案可以参见。然而由于本地缓存等问题的限制，网络共享存储的方案在性能上出现较明显性能问题，且大都为基于C/C++的底层改动，改造成本出现不收敛情况。而当时集团GitLab服务器在高峰期CPU屡屡突破**95%**甚至更高的警戒值，而高负载也导致了错误请求占比居高不下，无论是对上游应用的稳定性还是对用户体验都提出了严峻挑战。2016年8月起新一轮改造开始。三、改造方案既然共享存储的方案暂时行不通（后续如果网络存储的读写性能有质的提升，未尝不是好的方式），首先明确了唯有分布式或者切片才能解决问题的基本思路。我们注意到，GitLab一个仓库的特征性名称是\"namespace_path/repo_path\"，而且几乎每个请求的URL中都包含着个部分(或者包含ID信息)。那么我们可以通过这个名称作分片的依据，将不同名称的仓库路由到不同的机器上面，同时将对于该仓库的相关请求也路由到对应机器上，这样服务就可以做到水平扩展。下面通过一幅图介绍一下目前集团GitLab在单个机房内的架构。3.1 各个组件的功能主要是：Sharding-Proxy-Api用于记录仓库与目标机器之间的对应关系，可以看作切片的大脑Proxy负责对请求做统一处理，通过Sharding-Proxy-Api获取信息，从而将请求路由到正确的目标机器Git Cluster由多组节点构成，每组节点内有三台机器，分别为master，mirror和backup。其中master主要负责处理写（POST/PUT/DELETE）请求，mirror主要负责读（GET）请求，backup作为该节点内的热备机器说明master在处理完写请求后，会同步更新此次变更到mirror和backup机器，以确保读请求的正确性和热备机器的数据准确之所以没有采用双master的模式，是不想造成在脏数据情况下，由于双向同步而造成的相互覆盖3.2 保证方案可用如何确保切片信息准确Sharding-Proxy-Api基于架构开发，实时接收来自**GitLab**的通知以动态更新仓库信息，确保在namespace或project增删改，以及namespace_path变更、仓库transfer等情况下数据的准确性。备注：这样的场景下，等于每次请求多了一次甚至多次与Sharding-Proxy-Api的交互，最初我们曾担心会影响性能。事实上，由于逻辑较为简单以及golang在高并发下的出色表现，目前Sharding-Proxy-Api的rt大约在5ms以内。如何做到切片合理性海量数据的情况下，完全可以根据namespace_path的首字母等作为切片依据进行哈希，然而由于某些名称的特殊性，导致存在热点库的情况（即某些namespace存储量巨大或者相应请求量巨大），为此我们为存储量和请求量分配相应的权重，根据加权后的结果进行了分片。目前来看，三个节点在负载和存储资源占用等方面都比较均衡。如何处理需要跨切片的请求GitLab除了对单namespace及project的操作外，还有很多跨namespace及project的操作，比如transfer project，fork project以及跨project的merge request等，而我们无法保证这些操作所需的namespace或project信息都存储在同一台机器上。为此，我们修改了这些场景下的GitLab代码，当请求落到一台机器同时需要另一台机器上的某个namespace或project信息时，采用ssh或者http请求的方式来获取这些信息。最终的目标是采用rpc调用的方式来满足这些场景，目前已经在逐步开展。3.3 提升性能ssh协议的替换目前阿里巴巴集团GitLab提供ssh协议和http协议两种方式，供用户对代码库进行fetch和push操作。其中，原生的ssh协议是基于操作系统的sshd服务实现，在GitLab高并发ssh请求的场景下，出现了诸如这样的bug：由此产生的问题是：ssh协议登陆服务器变慢用户通过ssh协议fetch和push代码时速度变慢为此，我们采用golang重写了基于ssh协议的代码数据传输功能，分别部署在proxy机器以及各组节点的GitLab服务器上。由此带来的好处有：机器负载明显降低消除上述bug在ssh服务发生问题的情况下，仍旧可以通过ssh登陆（使用原生）服务器，以及重启sshd服务不会对服务器本身造成影响下图是proxy机器采用新sshd服务后的cpu使用情况：个别请求的优化和重写对于一些请求量较大的请求，例如鉴权、通过ssh key获取用户信息等接口，我们目前是通过文本转md5，加索引等方式进行性能优化，后期我们希望通过golang或java进行重写。3.4 确保数据安全一主多备如上面提到的，目前阿里集团GitLab的每组分片节点包含有三台机器，也就是相对应的仓库数据一备三，即使某一台甚至两台机器发生磁盘不可恢复的故障，我们仍旧有办法找回数据。跨机房备份刚刚过去的三月份，我们完成了阿里巴巴集团GitLab的跨机房切换演习，模拟机房故障时的应对策略。演习过程顺利，在故障发生1min内接到报警，人工干预（DNS切换）后5min内完成机房间流量切换。多机房容灾的架构如下图所示：保证准实时的仓库数据同步是机房切换的基础，我们的思路按照实际需求，由容灾机房机器主动发起数据同步流程，基本步骤是：利用GitLab的system hook，在所有变更仓库信息的情景下发出消息（包含事件类型及时间包含数据等）同机房内部署有hook接收服务，在接收到hook请求后对数据进行格式化处理，并向的相关主题发送消息容灾机房内，部署有消息消费服务，会订阅相关的MNS主题以实时获取online机房发送到主题内的消息，获取消息后调用部署在容灾机房GitLab节点机上的rpc服务，主动发起并实现数据同步的逻辑hook接收、消息消费以及**GitLab**节点机上的rpc服务，均由golang实现。其中rpc服务基于，采用来序列化数据。通过一段时间的运行和演习，已经确定了方案切实可行，在数据校验相关监控的配合下，容灾机房可以准实时同步到online机房的数据，且确保99.9%至99.99%的数据一致性。3.5 如何提升系统的可用性日志巡检面对集团GitLab每天产生的大量日志，我们使用阿里自研的监控工具进行日志监控，对系统产生的5xx请求进行采集和报警，然后定期去排查其中比较集中的错误。经过一段时间的排查和处理，5xx错误日志大致可以分为：分布式改造带来的跨分片操作的bugGitLab本身的bug高并发情况下带来的系统偶发性故障数据库相关的错误等由于用户量大，场景多，阿里巴巴集团GitLab的使用场景基本覆盖GitLab的所有功能，因此也可以暴露出一些GitLab自有的bug。如（从此，咱也是给GitLab供献过代码的人了）。服务器监控无论系统多少健壮，完备的监控是确保系统平稳运行的基础，既可以防患于未然，也可以在问题出现时及早发现，并尽可能减小对用户的影响。目前阿里巴巴集团GitLab的监控主要有：机器cpu，内存、负载等基本指标的监控ssh、ping等网络检测信息（用于判断是否宕机，后将详述）服务器各个端口的健康检查（80，90xx，70xx等等）异步消息队列长度的监控数据库连接的检查错误请求的监控Sharding-Proxy-Api与GitLab的数据一致性校验很自豪的一点是，我们经常可以根据报警信息，先于用户发现问题。单机故障的自动切换虽然监控足够完备，但谁也不能保证服务器永远不宕机，因此我们在同一组节点中保有一台backup机器以应对服务器故障。会有专门的client定期通过API轮询监控平台提供的机器监控信息，当确认机器宕机时（ssh和ping同时不通，且持续时间超过2min）自动触发机器角色的互换，包括master与backup互换，mirror与backup互换等。通过演习，我们已经具备了单机故障时5min内全自动实现机器切换的能力。机房故障时的切换即前述的跨机房切换。3.6 单元化部署单元化架构是从并行计算领域发展而来。在分布式服务设计领域，一个单元（Cell）就是满足某个分区所有业务操作的自包含的安装。而一个分区（Shard），则是整体数据集的一个子集，如果你用尾号来划分用户，那同样尾号的那部分用户就可以认为是一个分区。单元化就是将一个服务设计改造让其符合单元特征的过程。为了实现单元化的目标，我们在最初设计时就往这方面考虑。比如跨机房备份中，消息消费应用需要调用**Sharding-Proxy-Api**获取rpc服务的地址时，尽可能做到数据在单机房内闭环。这样在满足单元化要求的同时，也可以在机房故障时，尽量不影响已进入队列的消息在消费时出现数据断流。现在阿里巴巴集团GitLab在架构上已经基本具备了单元化部署的能力，这样的情况下，无论是后续与阿里云合作对外提供服务，还是当收购海外公司需要单独搭建新服务时，都不会遇到问题。四、未来的改进4.1 偶发的cache大量释放由于GitLab有大量的IO操作，使得系统占用cache的数值巨大，也正是因为cache，系统的性能得到保证。然而成也cache败也cache，为了确保系统不会发生OOM，我们设定了vm.min_free_kbytes，当cache占用过多且需要继续申请大片内存时，会触发cache的释放，势必会影响释放瞬间请求处理能力（通过日志分析得到，此瞬间的处理能力仅为cache存在时的1/2左右），直接后果是该瞬间的请求堵塞，甚至出现部分502。为此我们咨询了系统部的同学，根据他们的建议修改了部分内核参数（目前仍没有根治），后续会尝试升级内核的方式，也希望遇到过类似问题或对这方面问题有研究的同学，把你的秘籍传给我们。4.2 自动化运维目前集团GitLab的发布主要靠手，在分布式架构下，机器势必越来越多，全自动化的发布、扩容机制，是我们需要完善的地方。4.3 rpc方案的最终落地如前所述，只有最终实现了全局的rpc替换，才能将web服务所消耗的资源与Git本身消耗的资源进行分离，阿里巴巴集团GitLab的分布式改造才能算最终结束。后续
监控及日志数据对比显示，过去一年中阿里巴巴集团GitLab请求量增长4倍，项目数增长130%，用户数增长56%，在这样的增速下，系统调用的正确率却从99.5%提升到了99.99%以上，这些数字印证了我们方案的可行性和可用性。
接下来的时间里，小伙伴们会为继续代码服务的创新而努力，“高扩展、分布式、响应式、大文件、按需下载、流控、安全、数据化、单元化”，有些我们做到了，有些是接下来努力的方向。
现在阿里巴巴集团GitLab的架构，已经足够支撑百万规模的用户体量。在经过阿里工程师、开发者的千锤百炼之下，我们有勇气和信心通过为更多的开发者提供代码托管服务，共同打造云上的协同研发生态！本文作者：
屹恒有关：阿里云 code 这是一款从未在外面推广过的代码托管产品，估计很多人还不知道阿里云有这个服务。阿里云code旨在解决部分中小企业选择内部自行搭建 Git或SVN ，势必会遇到搭建、维护成本高，难于扩展和备份，数据安全和可靠性差的问题。核心优势——阿里云上基于Git的分布式代码托管，高可用、安全、高性能以及无限容量是其核心竞争力，支持svn仓库的便捷迁移。目前已面向个人或企业免费提供Git及SVN两种协议模式的代码托管服务：","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T11:58:19+08:00","url":"/p/","title":"阿里是如何打造支撑百万用户的分布式代码托管平台？","summary":"本文主要介绍了阿里巴巴集团代码服务团队，在过去一年基于GitLab进行的代码托管分布式改造，希望与大家进行分享与探讨，为云上开发者提供更好的代码托管服务。本文由： 提供 一、背景介绍毋庸置疑，代码是DevOps流程的起点，是所有研发流程的基础；…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":7,"likesCount":21}},"annotationDetail":null,"commentsCount":3,"likesCount":15,"FULLINFO":true}},"User":{"a-li-yun-yun-qi-she-qu-48":{"isFollowed":false,"name":"阿里云云栖社区","headline":"“云栖社区”是阿里云官方开发者技术社区，聚焦于传播云计算、大数据等DT时代核心技术的内容与资源。","avatarUrl":"/v2-8f5f8eefcb27de64ffbefee_s.jpg","isFollowing":false,"type":"org","slug":"a-li-yun-yun-qi-she-qu-48","bio":"汇集阿里技术精粹，","hash":"65b52731faea3de2ef3fffa1","uid":282900,"isOrg":true,"description":"“云栖社区”是阿里云官方开发者技术社区，聚焦于传播云计算、大数据等DT时代核心技术的内容与资源。","profileUrl":"/org/a-li-yun-yun-qi-she-qu-48","avatar":{"id":"v2-8f5f8eefcb27de64ffbefee","template":"/{id}_{size}.jpg"},"isOrgWhiteList":true,"badge":{"identity":null,"bestAnswerer":null}}},"Comment":{},"favlists":{}},"me":{},"global":{},"columns":{"next":{},"yunqichengxuyuan":{"following":false,"canManage":false,"href":"/api/columns/yunqichengxuyuan","name":"我是程序员","creator":{"slug":"a-li-yun-yun-qi-she-qu-48"},"url":"/yunqichengxuyuan","slug":"yunqichengxuyuan","avatar":{"id":"v2-f41c4ececa862f50bdaa851db41c3f54","template":"/{id}_{size}.jpg"}}},"columnPosts":{},"columnSettings":{"colomnAuthor":[],"uploadAvatarDetails":"","contributeRequests":[],"contributeRequestsTotalCount":0,"inviteAuthor":""},"postComments":{},"postReviewComments":{"comments":[],"newComments":[],"hasMore":true},"favlistsByUser":{},"favlistRelations":{},"promotions":{},"switches":{"couldAddVideo":false},"draft":{"titleImage":"","titleImageSize":{},"isTitleImageFullScreen":false,"canTitleImageFullScreen":false,"title":"","titleImageUploading":false,"error":"","content":"","draftLoading":false,"globalLoading":false,"pendingVideo":{"resource":null,"error":null}},"drafts":{"draftsList":[],"next":{}},"config":{"userNotBindPhoneTipString":{}},"recommendPosts":{"articleRecommendations":[],"columnRecommendations":[]},"env":{"isAppView":false,"appViewConfig":{"content_padding_top":128,"content_padding_bottom":56,"content_padding_left":16,"content_padding_right":16,"title_font_size":22,"body_font_size":16,"is_dark_theme":false,"can_auto_load_image":true,"app_info":"OS=iOS"},"isApp":false},"sys":{}}