qq_32532853的博客

之前通过TIDB了解到了LSM Tree，优化了数据库的写入的速度，在mariadb下，也有一个基于LSM的存储引擎Myrocks，他也支持事务，目前也是稳定版本，最近有时间学习了下。目前10.7windows版本里面是自带myrocks的，只是默认没有起来，配置my.ini后，show engines就可以看到了。为了测试真实的效果，我建了一个带主键和二级唯一索引的myrocks用户表，主键采用自增，二级索引是字符串类型，写入的字符串是36位uuid。用java程序拼好sql后，直接写入数据库。从写入

我们要增加一个检查商户的输入商品介绍有没有不合规的单词的功能，淘宝也有类似的功能。这个规则是需要根据线上的用户输入不断更新的，这个逻辑放到代码里面是不合适的，需要查找一个规则引擎。之前就了解过规则引擎，从网上搜了一下drools，看了它的优缺点，我觉得最主要的缺点是，1.学习成本高，有的人光学习部署他就花了3个月，规则语言学习起来和学习一门新的语言差不多了。2.规则生成的代码没有办法单步调试。

我们之前开发的系统是第一次基于springboot开发的，在测试阶段一直被一个问题困扰，就是程序莫名其妙就killed，没有打印什么堆栈内存不够的信息，用jamp -heap 命令也没有查找到内存有泄漏的问题。怀疑是内存不够，但是free -m看了一下，内存应该是足够的。只好在网上搜索，还真在Stack Overflow上面找到了一点提示，就是和系统的内存分配是有关系的，建一个swap空间就可以解

我们之前版本的支付中心实现了不同支付方式统一的接口，但是后面向第三方请求的时候，只设计了单一配置，即只能以同一个账户和第三方支付公司发生交易，并且支付记录的保存并不完善，不能从支付中心直接查出来支付的总量。随着公司业务的扩大，我们来自不同产品线的支付需求要求支付账号可能是多个，也可能是跨公司主体的。为了更好的服务不同项目，我对原来的支付中心进行了重构。1.支付中心采用一套统一的接口来对外提供服务，...

我们最近又对系统进行了一次大的改版，主要的改动为:1.原来的sql都是联表查询，把主要的运算交给了数据库，这版改成了全部单表查询，需要应用程序自己组织返回结果，因此在程序中大量定义vo，从数据库vo到参数vo到返回vo，这样为未来的数据任意扩展提供了可能（可以迁移到其他的nosql数据库上）2.对于redis的运用，原来偏向于把它当成临时缓存，现在偏向于把它当成加速的数据库，用到了redi...

产品经理不清楚我们的接口给用户返回的具体的提示信息是什么，有一些可能是程序员能看懂，但是对用户不友好的提示。产品就想看一下，如果需要修改，则修改了，用户看到的是修改后的提示。这个需求如果是对于一个新项目来说，可以将所有返回给用户的提示，单独配置到配置文件中，产品就可以直接看配置文件，修改配置文件了。但是对于一个已经运行的线上系统来说，这样改动的话，范围太大了，再有就是有一些是第三方平台返回给我...

我们原来用的httpClient一直都是com.ning.http.client.AsyncHttpClient(线程池管理类)，需要的时候申请，不需要的时候释放。并发比较高的情况下，存在http链接不释放的问题，升级了版本也解决不了，我最近对它进行了一次重构，彻底解决了这个问题替换的思路就是用ThreadLocal来为每一个线程分配一个HttpClient，使用后自己释放链接，这样每个线程就...

tidb这种行式数据库确实不是存储日志用的，但是对于tidb这种新数据库，我们从引入到部署到核心系统，需要一个熟悉的过程，用户行为数据不是核心数据，就算是数据丢失，也没有什么问题，因此就从这个系统引入了tidb

我们新开发了一个电商平台，需要实现附近的店铺功能，经过预研，觉得没有必要采用mongodb的地理位置查询功能，因为涉及数据同步，还有联合索引的问题。直接用MySQL5.7内置的距离计算功能就可以满足大规模计算距离的需求。计算附近的店铺时侯，一般的需求是传入用户的坐标，需要计算出附近的店铺，按照用户和店铺的距离排序返回前端。在成千上万家店铺选择附近的店铺就涉及效率的问题了。最好的方式是先找到附近...

最近做了一个新的电商平台，本质上还是一个电商场景下的借条平台，其中的设计有对于之前设计的借条平台的完善，这里整理一下。1.对于原来统计系统的完善，原来的数据都是数据一旦不再更改后，直接导入历史表，这种设计对于业务系统来说，是能保证业务系统的数据最小，但是对于当天的数据统计，则是一个麻烦，需要统计历史表，统计时间比较长，客户体验比较差。这一次改为每天晚上定时任务跑，在统计完当天的数据后，再导入到

我们每天凌晨都要跑一个定时任务，插入逾期记录，并且重新计算用户的逾期，待还，待收等各种统计。前两天发现线上的逾期太多了，定时任务都跑到下午了。因此决定对定时任务进行优化，让他在凌晨跑完。定时任务是按照借条分期来处理的，每张借条分期插入逾期记录，更新借条分期信息，更新借条信息，更新相关用户的各种统计信息。最先想到的优化办法是采用多线程，同时跑他50个线程，同时把可能产生互相锁表的用户统计采用sq

我们支付接了多家通道之后，支付路由就是一个绕不过去的问题了。因为许多通道都有同卡进出的要求，因此不能简单地把所有支付的流程全部抛给支付模块，业务系统只关心支付结果。因此我们的支付路由设计得比较轻。当业务系统发起支付请求的时候，需要先带着支付四要素和支付用途先查询支付模块一次，看走哪个通道比较合适，然后再按照返回的结果来调用支付统一接口来进行支付。这样，当支付必须走某一个通道的时候，可以不用查询支付

我一开始来公司的时候，公司只有两个刚毕业的前端，前端也仅仅是基于jquery，那个时候，我还是第一次经历这种前后端分离的组织架构。开发时间也是大大的高于预期，我很快意识到这种组织结构是弊大于利的。随后我做的企业博客项目由于前后端都是我一个人开发，项目时间和进度都和估计的差不多，用时远远低于前后端分开开发的时间。随后我需要对核心业务进行一次彻底重构，这个时候我们前端想要进步，想用先进的技术组...

我们最近对账的时候发现，有一些和第三方支付公司的交易，没有被mysql数据库记录下来。查了下日志，只有请求，没有响应。想了想，应该是服务器重启的时候，第三方支付公司的请求还没有返回，原来执行的sql回滚了。原来用的weblogic服务器就没有这样的问题，因为在重启的时候，weblogic服务器会一直等待所有的请求都返回，所有的事务都处理好了，才会真正重启。但是jetty服务器告诉他重启，什么都不等