这里整理了一些学习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…
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…
Charles APP代理软件 Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all…
让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…
小型服务端系统架构 一般的后端系统的工作模式。 目前，大部分服务端软件都会选择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来完成整个系统的需求，每个模块内部都可以加入一些防护措施，就算在血崩的时候也可以有选择的余地，具体的在后面的文章会继续讨论。