自家在BAT学到的技术工具-使用nodejs搭建辅助高产出的http服务

四、命令行or图形界面?

两头没有本质区别,图形界面末了也如故触发命令。直接用命令行能更好了然整个操作的历程。

图形界面则操作便利。但新手一定要对图形界面中的参数保持敏感,可能多勾了采用结果就完全不相同,比如–force。。。

3. 遵照nodejs的技巧方案

  • nodejs完成连接接入,结果处理拼装的干活,其中使用到了多少个很好用的插件。
    pm2:
    类似服务端的supervise,当进程意外崩溃后自动重启动;
    ![示例](http://7u2g5z.com1.z0.glb.clouddn.com/屏幕快照
    2015-01-08 早上6.31.43.png)
    鉴于nodejs是单进程模型,pm2帮助活动部署为多进程运行,可以更好的采纳服务器cpu;

    redis:支持的nodejs的redis proxy

  • redis
    应用了set作为value类型,牺牲局部属性达到去除重复标签的效应。

  • 管理redis的web 工具
    redis-commander
    ![示例](http://7u2g5z.com1.z0.glb.clouddn.com/屏幕快照
    2015-01-08 早上6.20.30.png)

一、安装

劳务器端不开展,因为根本面向搬砖的码农。

客户端可参见大神 廖雪峰
Git教程-安装git

亟需特别表达的是,在windows中,msysgit才是真的的git客户端,乌龟tortoisegit只是个界面。mercurial和sourcetree也是近乎道理。

4. 效用统计

  • 实则压力测试,读写混合的pv单机可以在1W qps左右。
  • 小结nodejs适合采用场景:高并发流量,不是很重的拍卖逻辑,http服务层。

不都是SCM代码管理嘛,有很大区别么?很多svn老鸟都是抱着这么的心情去学习git,然后无一防止地陷入“查阅过很多资料,依旧左右不好”的窘境,至少大家集团是这般的。

2. 可选的技能方案

图片 1

2种技术方案A/B

  • php 使用lighty 配置fastcgi模式
  • nodejs使用lighty配置redirect模式
  • 鉴于搜索焦点的流量经过php集群,所以,这次从支付效用,并发请求协助效率(单机qps)上考虑使用nodejs搭建后端服务

二、本地版本库

又见
工作区和暂存区

此处容易是初学者容易踩坑的地点,代码只交付到当地版本库,却未曾推送到长途版本库。(其实是选型的人的反人类设定吧,用分布式的工具去做集中式的管住。)

svn是本地-远程两层的结构,而git则是工作区-本地-远程三层的协会。

在客户端看的看来的源码文件是工作区,提交到的是当地版本库,本地版本库的改动假设不推送,就是单机自己玩,不会影响其旁人。

1. 面对的要求

![tag标签维度](http://7u2g5z.com1.z0.glb.clouddn.com/屏幕快照
2015-01-08 傍晚5.43.22.png)

  • 接口表达

    1. 收获指定图片中的tag内容
      输入:objurl,userid
      输出:tag list

    2. 得到指定话题(如:”G-SHOCK”)下面所有的图形
      输入:tagname
      输出:objurl list,tag desc 等信息

    3. 为某个图片添加标签tag
      输入:objurl, userid,
      tagname(这些为了归一化,前端会有选取携带)
      输出:是否成功

五、分支管理

查看过不少git分支管理的资料,依旧用得不好,直到踩过多少个月的坑。。。

git的起点是开源系统,思想是分布式、去中央化,用svn的集中式管理是很容易踩坑的。

率先,svn是针对性文件内容的对待,而git是指向文件增量和提交时间的自查自纠,四个人的多次的争持合并极容易发生错误。

援助,git的去中央化思想认为每个开发者都是驾轻就熟的负总责的。而事实上不是的,假如社团里有一六个“流氓”,境遇争执没有细看,直接–force或use
mine,测试会抓狂的,然后开发和项目经理都会抓狂的~

然后最终,你便会质疑:为何不用svn啊?git跟svn没什么区别啊,还更难用!

且看看开源项目对git是怎么用的。 Git使用专业流程 开发者先fork复制出自己的库(远程),然后一文山会海的开支(本身也得以有分支管理),push上和谐的远程库后,再pull
request提交给管理员review和归并。而开源项目标发布,是有stable和nightly
update等不同的宣布版本。

回过头来看,集团公司里的项目要什么管理git的版本和分支呢?

图片 2

上图 git flow
便是最完好最不利的分支管理模型了。

此地有四点血泪经验要谨记:

1.不要吝啬开分支,git开分支的代价很小。

2.统一是容易出事的环节,要让负总责的熟手来把关。

3.以feature划分开发分支是老大好的思想形式,把互相依赖的内容放在一起、把不相干的情节隔离开、让“这些功效暂时不上”这种需要变更变得实惠。

4.分支是活的、会改变的,标签tag才是一个老少咸宜的版本。

 

至今,使用git做源码管理的门类和社团足以运作起来而且可以规避大部分的坑。要用得更溜的话可以继续精修patch、rebase、revert、–fast-forward、cherry
pick等更高阶的用法。

最后彩蛋:老车手和好提示,请把eclipse项目文件、编译后文件(文件夹)参预.gitignore文件,那个题目在svn就存在了~

三、相关命令和争持合并

命令方面材料很完美,我就不重复造轮子了。见上文的Git教程。

指令的查看很流行这种叫Cheatsheet(考试舞弊的小抄么?)速查手册,也是一搜一大把~

比如 http://ndpsoftware.com/git-cheatsheet.html
清晰地指出从哪个区到哪个区对应的通令是怎么~

图片 3

又比如说上图,图示表明了碰到各个场馆应该咋办。

有关争执,都是爆发在跨分支或跨库的修改。比如,工作区的改动未commit而pull远程的翻新时会报错(要先commit),本地库push发现远程库有其别人付出时会报错(要先pull并在本土解决争执),暂存区取回stash
pop时可能暴发争持。

而当合并暴发争辨需要手动解决时,svn老鸟肯定是懵逼的,三路相比较合并,哪个打哪个啊。。。这是因为,在svn中只有“我和中心库”的龃龉,而git中却是“我和他”的争执。

由此在git中做联合有五个源:base是分支的同台祖先,local是本地仓当前支行,remote是要从这么些分支合过来,output当然就是联合结果的预览啦。

详见 对此化解 Git 的 Merge Conflict
你有什么经验和技能?

网上的资料确实已经重重了,却尚无把全体文化结构串起来。通读《git权威指南》是卓有功效的,只是我们都急着用,没这耐性。我那里熬一碗鸡汤,整理供我们享用。

发表评论

电子邮件地址不会被公开。 必填项已用*标注