现在更多的已经使用新的前端技术栈了,但是对于我这个陈年老后端来说,jquery还很勉强,所以....... 如果还是使用jquery来进行ajax调用的话,就一定会遇到ajax返回值的问题. 我们在写代码的时候一般会这么写一个ajax方法: function getInfo(id) { if(id == 0 || id == undefined) { return false } $.ajax({ type: "get", url: "xxx", success: function (res) { if(res.errNo == 0) { return res.data; //类似这样的写法.是有问题无法返回的.因为是异步请求. } }, }); } 那把上面的代码改一改应该就可以了,网上搜罗一大堆博客,会告诉你应该这么搞: function getInfo(id) { var response = ""; if(…

拖动排序的后端到底应该咋实现。…

介绍mysql慢查询产生的情况和mysql慢查询造成的一些影响. 常见的mysql慢查询情况.…

问题的现象:1,每个整点前后,集群会出现少量的4xx和5xx请求. 2,每个整点前后,集群的所有下游请求(codis,mysql)耗时 都会有比较小的抖动. 3,每个整点前后,当前集群的上游集群也会出现少量的4xx和5xx问题. 20日前后, 集群开发爆发大量的整点5xx和4xx错误.持续时间1-2分钟不等.后面会自动恢复. 开始着手排查 措施之一:扩容 20日后有明显的流量变更,开放了流量入口.但是按照机器资源的使用情况来看,问题与故障出现在整点.所以和流量非正相关. 但是考虑到增加容量可以暂时缓解问题.并且集群容量阈值也偏低.  故申请了两台机器扩容到集群上. 问题有所缓解,但没有找到根因.没有彻底解决. 逐步排查过程:观察集群日志和响应时间,可以确定集群在整点前后,所有下游请求和上游请求的整体耗时都有增长. 超过了能够承载的平响时长的临界值. 按照计算.集群7台机器.每机器开启512个php-CGI进程处理请求. 整体平均响应时间为15ms左右(nginx/access.log统计) . 在流量高峰的时间内,整个机器的单机平均QPS在2800左右. 如果QPS 保持不变.去计算平均响应时长的极限值情况. 1000ms/…

原文地址：https://eddycjy.com/posts/go/go-moduels/2020-02-28-go-modules/ 感谢原来的作者 Go modules 是 Go 语言中正式官宣的项目依赖解决方案，Go modules（前身为vgo）于 Go1.11 正式发布，在 Go1.14 已经准备好，并且可以用在生产上（ready for production）了，Go官方也鼓励所有用户从其他依赖项管理工具迁移到 Go modules。 而 Go1.14，在近期也终于正式发布，Go 官方亲自 “喊” 你来用： 因此在今天这篇文章中，我将给大家带来 Go modules 的 “终极入门”，欢迎大家一起共同探讨。 Go modules…

原文地址：https://eddycjy.com/posts/go/go-moduels/2019-09-29-goproxy-cn/ 感谢原来的作者。 大家好，我是一只普通的煎鱼，周四晚上很有幸邀请到 goproxy.cn 的作者 @盛傲飞（@aofei） 到 Go 夜读给我们进行第 61 期 《Go Modules、Go Module Proxy 和 goproxy.cn》的技术分享。 本次 @盛傲飞 的夜读分享，是对 Go Modules 的一次很好的解读，比较贴近工程实践，我必然希望把这块的知识更多的分享给大家，因此有了今天本篇文章，同时大家也可以多关注 Go 夜读，每周会通过 zoom 在线直播的方式分享 Go 相关的技术话题，希望对大家有所帮助。…

整体背景：在一个用户充值的场景下，整体的处理流程如下： 在这个处理流程中，我们的插入流水信息和更新用户信息是针对同一个数据库的操作。但是用作缓存的是redis，通知支付系统是通过网络请求，很明显，这个处理流程中存在分布式的事务，那就是缓存的更新，以及通知支付系统的处理结果和数据库的写入需要包装成一个整体的事务。 用户充值的处理，是通过调度任务来进行调度的，如果调度任务得到的结果是处理失败，那么间隔一定时间后，还会来重试请求。 在整体的实现过程中，开启了数据库的事务来处理插入流水和更新用户信息两个细节。在这个事务中，同时又针对更新redis缓存和通知支付系统两个环节的返回来判断了事务是否进行提交。整体的处理流程图如下： 这里不去讨论分布性事务的具体实现，我们只是来看这个处理流程，在这个处理流程中，redis的缓存更新 ，可以进行cancle（删除写入的数据即可），但是通知订单系统这个操作是不能够进行cancle的  ，数据库的执行是能够不提交的。整体上讲 。这应该是一个不典型的TCC分布式事务。这整个的处理流程中，存在一些比较棘手的情况。如下 遇到的问题在这里比较难以处理的是  如下两种情况： 第一种情况：当我更新缓存成功了，但是通知订单系统失败了，此时我是否应该提交事务。 第二种情况： 当我最终处理完成的时候提交事务失败了，此时写入到缓存的数据是否需要也和数据库保持强一致性。 针对如上两种情况的处理： 如果更新缓存成功，但是通知订单失败了，此时我们选择了提交事务，同时更改了逻辑，以抛出异常，让调度任务能够捕获异常，…

背景典型的APP设计。客户端和服务端之间的交互是一个重要的环境。几乎没有APP能够保证不和后端通信。同时受限于客户端版本发布的掣肘。很多时候后端接口的升级无法实时反映到客户端。但是很多时候后端相关接口的升级又势在必行。 例子1： 读取客户端用户信息的接口上面。最近增加了用户等级相关的信息。客户端发版要在一周之后，但是客户端在渲染用户界面的时候没有对用户等级信息字段做相关解释。或者在协议中没有针对用户等级的解释。如果贸然增加字段，会导致客户端不可预期的结果。这个时候需要针对不同版本做相关的逻辑。老版本不动，新版本增加新的字段。 例子2： 如果服务端想要做模块划分。或者独立出来某些功能。那么需要在客户端针对一组URL做相关的改动。这个时候就会出现客户端需要在新版本中针对url做批量改动。同时在服务端又需要针对老版本的客户端做兼容工作。如果发布的版本较多。那么就会出现多个版本的接口并行的情况。流量一直要持续到版本的迭代周期，短则几个月，长则一两年。 针对以上情况，如果是小规模的app，管理起来还可以维护，但是如果规模较大。往往多个模块和多个功能分别部署与多个集群。那么就是同一组功能的多个接口部署在不同的集群上面。要同时维护的内容就变成了一个乘积。 只有逻辑接入层的部署结构如下图： 接入层的解决方案 如果是大厂一类的公司。一般会有比较完善的统一流量调度层。如百度的BFE 。通过这一层，根据不同的请求path将流量转发到不同集群。但是设计此层面的更大作用是流量调度。流量保护等相关事情。对于深入到业务的事情，接入层也无能为力。并且一般接入层的设计是不侵入业务的，也就是说接入层只用来管理流量。不关注具体的业务实现。 接入层的功能往往不能满足业务的相关需求。…

CGI 通用网关接口（Common Gateway Interface/CGI）是一种重要的互联网技术，可以让一个客户端，从网页浏览器向执行在网络服务器上的程序请求数据。CGI描述了服务器和请求处理程序之间传输数据的一种标准。 --以上来自维基百科. [也就是说这个只是一个协议] https://zh.wikipedia.org/wiki/通用网关接口#外部链接 通用网关接口最开始设计是为了解决各种不同计算机系统交换数据的问题. 我们把实现了这种协议的程序叫做CGI程序. 大多数语言都可以实现CGI协议. shell ,c++ ,php  python 等等. 只要你满足协议的要求即可. 想了解更多可以阅读 https://web.archive.org/web/20100127161358/ http://hoohoo.ncsa.illinois.edu/cgi/ 大多数实现了CGI 的程序使用的都是一种 比较典型的prefork的方式.即每处理一个请求,就启动一个进程.处理完成后进程退出. 这样在早期的时候是可以的,因为请求量不大,那时候可能还没有并发的概念.…

引言：提到服务端编程，很多时候写的就是IF/ELSE,一些简单的CURD操作。作为服务端编程的同学，每天面对的很多是很简单的逻辑，简单的逻辑里面又有着不同寻常的事情。 海量请求的情况下，就会发生量变引起质变的过程。如何优化你的系统，优化你的接口，优化你的服务。让你的服务跑的更欢快。下面一起来讨论一下。 ROUND 1  最简单的系统能想到的最最简单的系统，可能就是简单的静态网站了，只要有一个web服务器，就能够实现服务。 举个例子： 简单的静态宣传页面。大网站的静态页面。 静态页面的整个服务流程中，从请求的发起到正常的响应，整体流程很简单。 用户通过URL发起一个域名相关的请求； 请求到达DNS服务器，找到相关的ip地址。通过ip访问主机，获取数据，得到数据后访问设备（浏览器）通过数据去渲染。用户就看到了最终的呈现。 我们来假设一个系统，有一个某公司的宣传页面。是一个单纯的静态页面，部署于单机的一台静态服务器上面。页面上面设计比较多的静态资源（图片，js文件等。） 如果你发现你的静态单页面访问速度不是很理想，访问速度比较慢，加载比较慢等等问题。 能出问题的方向无非下面几个： DNS解析时间过长： dns的解析时间。优化dns服务器，…