Git 相关的一些问题

Git 相关的一些问题

这里整理了一些学习Git过程中遇到的一些问题,大部分的解决方案都来自Stackoverflow。这些问题比较散乱,相互间联系很弱,但是都是一些很容易遇到的问题,有较高的使用价值,所以整理一下,作为日后参考。 1.【git error object file is empty】git error object file is empty 2.【Git 删除远端已经合并的分支】在开发过程中,尤其当团队比较大的时候,项目成员比较多,git的分支可能会会多。好多已经开发完成并合并到主干的分支,都一直保存着,当你执行一个统计,分支少则几十个,多则几百个,虽说远端分支不太影响,但没用的东西,尽量还是清理掉,保持简单,高效。如题,在工作中,我遇到了这个问题,我的第一想法是google这个问题,找到了stackoverflow上的一个回答。删除远端的已经合并的分支,删除这些分支是没有任何影响的,因为这些分支所有代码都在master中了,所以请尽管删除git branch -r –merged | grep -v…

Read More Read More

Tmux 入门

Tmux 入门

tmux 简介 这里简单介绍一下tmux,tmux是一个终端复用软件,类似的工具有screen,现在screen用用户越来越少了,tmux大有一统江湖的趋势,先介绍这么多,来看2张效果图: 有时候,我们需要开多个terminal,大部分情况下,我们可以通过多个tab来完成。但是在我们不需要全屏展示的时候,这样感觉浪费。比如说我们需要一边写代码,一边看log,一边调试代码。这个时候,用多个tab的方式,效率就比较低了。有tmux之后,我们就可以都在一个terminal中完成这个操作了。如果再服务器上工作的话,在服务器上安装了tmux之后,我们就能通过一个ssh连接,开多个tmux tab,并且tmux tab还可以保存,我们可以在完成工作之后保存工作现场,等待下次进来之后,可以立即恢复到我们上次的工作场景中。 并且现在有了session恢复插件之后,就算tmux-server重启了也没关系,我们的session依然可以恢复。只需要在结束之前,进行一次保存,下次可以将新的tmux session恢复成原来的样子。具体的用法,请参考这个插件里面的介绍。 总之,linux软件,未经配置的和经过精心配置可以看起来完全是2个软件,当然这里指易用性。tmux同样也有很强的定制性,具体配置,可以参考我下面的配置。里面有一些简单的解释,不过不那么全。如果你很感兴趣,那么可以对其中自己不太明白的地方,自己搜索下,应该能获得很多新知识,可以帮助你更好的使用tmux。 如果你希望了解更多的tmux插件,你可以参考这个tpm tmux 配置 配置文件就不贴了,在这里可以看到, 完整的配置文件在这里tmux-conf.也可以看我的github-tmux-conf tmux-conf 配置文件依赖 tmux-version > 1.9 mac…

Read More Read More

网站域名HTTPS证书配置

网站域名HTTPS证书配置

让NGINX支持SSL 需要编译时支持ssl,可以sbin/nginx -V 来查看confiture参数,如果当时没有支持,那么需要重新编译安装。 编译参数前面已经有一篇文章了。nginx编译参数,也不用全加,用–with-http_ssl_module 就可以了。 生成证书 主要参考这个letsencrypty,可以生成免费证书。 生成方式也很简单,读上面的文章基本就能明白。ubuntu+nginx. ubuntu 用户的大致步骤如下: sudo apt-get install software-properties-common sudo add-apt-repository ppa:certbot/certbot sudo apt-get…

Read More Read More

小型服务端系统架构

小型服务端系统架构

小型服务端系统架构 一般的后端系统的工作模式。 目前,大部分服务端软件都会选择nginx,nginx轻量高效易扩展,在服务器领域应用越来越广泛。本文简单探讨下以nginx,php,mysql 为主要组件构成的后端系统的架构模型。图一,是一个一般的架构模型,下面我们将详细介绍一下其中的每一部分。 【lvs】这个一般是流量入口,在流量入口的机器中进行lvs的配置,将流量转发给不同的nginx去处理,这样一个集群就会有更高的业务处理能力。如果需要业务需要支持更多的流量,那么可以在这里直接平行扩展nginx的数量及其后面的系统节点即可。一般来讲,lvs因为只用来做流量的负载均衡,并不涉及请求的处理,所以一般不会成为瓶颈,如果不幸成为瓶颈了,也可以通过换更高配置的机器来解决。所以,一般来讲,业务系统的优化,指的是对lvs后面的那些模块的优化,例如业务代码的优化,让代码质量更高,运行速度更高,优化数据存储层,合理使用缓存组件,来降低系统的响应时间。 【nginx】这一层也是一个代理,对于php类型的请求,nginx其实自己是不会处理的,它在接到请求是所做的工作,实际上是将这些请求转发给配置中的fpm进程去处理,然后只负责接受fpm的返回结果送给请求方就完事了,因为工作简单,就是一个转发,就好像餐馆最外面的服务员一样,将用户招呼进来就完事了,所以,一般来讲,这种代理都不太会成为瓶颈,在这里,nginx仍然是代理,我们知道这一点就可以。 【FPM server】这些机上上,真正运行着fpm请求,真正的运行着我们写好的业务代码,用户请求的真正计算是在这些机器上完成。如果还用餐馆的例子的话,那么这里就相当于厨房的大厨了,他们的工作效率决定这餐馆的接客能力。如果要提高系统的服务能力,就要在这些机器上下功夫了。代码的优劣和我们系统的服务能力直接相关,所以一定要重视代码质量,一定要有代码review,注意核心逻辑的复杂度,一般来说循环会比较多,不要再循环内部做太多事情,复杂度这种算法素养,在工程中还是应该有所体现的,写代码的时候最好时刻带着这个意识。 【缓存层】一般来说,这个缓存层用redis的会比较多,redis也很适合来做这个事情。将mysql中的数据存在redis中,可以极大的减少mysql的压力,同时也能极大提高系统的响应速度,唯一的缺点就是,使用不当的话,可能引起数据更新不及时,但是使用得当的话,这些问题都是可以避免的。还有一个挑战就是运维能力,运维一个稳定的redis cluster 也是比较有挑战的,不过这是op的领域,但是如果没有op或者op不太行,你还需要搞,那可能就只能硬啃redis cluster 的文档了。一遍看不懂那几多看几遍,多花点时间和心死,我想应该也能搞出来。 【持久存储】这里的持久存储选择会比较多,我最熟悉的就是mysql了,应该mysql用得也很广泛,不过好像被orcal收购之后,出现了maridb,不过它们用法和特性很类似,其他的选择还有postgresql,也不错,怎么选看自己需要。使用mysql,一定要考虑下是否需要分库,如果业务发展比较快,mysql主库的资源,总会有用完的一天,当这一天来临的时候,你可能想将一台mysql机器扩展成2台或更多泰,当然这样做可行,但是前提是,你要讲所有的数据表从一个库拆分成2个或多个库。如果项目设计之初就考虑到了这个,那么在你进行分库拆分的时候会比较顺利,不会显得太痛苦。但是如果没有设计,没有提前考虑的话,当真个系统的所有表互相join在一起的时候,你想拆分的时候,你就会明白什么叫一团乱麻,更可怕的是,你面对的不是乱麻,而是一个个数据表,不是你想剪就能下手剪的。所以呢,最好再项目规划的初期,就能做一个考虑,合理的设计一下自己的框架,或者改造一下,以后的业务开发过程中,尽量不要做太多的表之间的依赖。这样一方面低效,一方面不利于维护。 [图一] 以上就是一个比较简单的服务端系统的轮廓。对于系统QPS大概在几百的小业务来说,这种架构应该足以应对。在一个创业团队初期,可以先选择这种简单的系统架构,这种架构简单,所以在一定的阶段内,实现成本和维护成本都相对较少。如果业务发展良好,用户快速增长,那么就要考虑在整个后端的服务架构方面做更进一步的投入了,因为这种架构的缺点远比它的优点多,如果突然有一天,你们的流量QPS到了1000或者更高,那时候你可能会对血崩这个词体会更深刻,那时候你们的服务应该是一片瘫痪,啥都干不了的状态,这显然不是很好……,如果要究其原因,你就会发现,你的架构其实很粗糙,并不能提供可靠的服务,血崩起来,真是啥都不可控。对于更为成熟的架构,应该是服务化的架构,它将本文介绍的这种混为一体的服务拆分成多个模块,然后通过各个模块间的call来完成整个系统的需求,每个模块内部都可以加入一些防护措施,就算在血崩的时候也可以有选择的余地,具体的在后面的文章会继续讨论。