Veitor
Veitor
从docker hub上直接使用你们的镜像后运行，使用默认配置 web domain是a.com，3000端口的 cli domain是a.com，8080端口， 那访问a.com:3000，页面上有js请求a.com:8080的接口，跨域问题 要是把web domain和cli domain 都处理成80端口，是有问题的，也行不通。。。所以当初你们是咋搞的？ 一定要在服务器上设置允许跨域的header？ 有没有其他方案？
I learned that type of `$job` in `yii\queue\Queue::push($job)` can be mixed except `JobInterface` instance. That meaings I can pass any type of parameter like string,array or object to this method....
这是什么问题？xunsearch不能restart，是不是tmp下的pid文件不对？ 并且此时有一个库莫名其妙的坏了，一直报错failed to open default db 最后！麻烦能否把xunsearch的bbs重新开放一下，里面有很多有用的历史交流信息，github上的issue有用的信息太少了。。。
在迁移迅搜数据库时，好像这两个文件会有一定影响。我看这两个文件是即时动态变化的，想了解一下两个文件分别是什么作用，我好采取相应的措施。 因为我现在需要将一台机器上的xunsearch/data迁移到另一个机器上去，数据量比较大，不打算采用新机器上重新索引（因为重建索引比直接复制慢，而且重建索引涉及很多表，没复制迁移来的方便）。 所以考虑rcv和snd文件可能是增量的数据，一种办法是我停止search服务，连通rcv和snd复制过去。不过我还是更希望不停服，所以我想针对rcv和snd特性想方案
I am curious about how to combine the `Specification Pattern` with the `Repository Pattern`. I hope the author can show a demo in the future.
我们迅搜每隔几天就会出现一次机器CPU飙高、内存耗尽、磁盘IO大到瓶颈的问题，致使机器宕机，最终排查下来，发现有一段逻辑导致的。 我们发现出现该问题的时间点基本都在深夜凌晨的时间段，一开始以为是有大量的任务在处理导致的，后来发现那段时间各种机器负载很低，访问量啥的也不大，但就迅搜的机器负载大到爆炸，最终通过一些监控信息和日志发现原因是在`commit index data`，在一个短短的1秒时间点内，产生了大量的`commit index data`日志。 对应到`index.c`中`db_commit_check()`方法，该方法会在indexd服务端退出时或闲时被执行，无论是退出还是闲时时被执行，`db_commit_check`都是被执行了，根据记录到的另外的日志信息，在宕机的时间点有过瞬间产生近数百个import进程，import的进程数量也与我们记录的`commit index data`日志条数相符，意味着确实是`db_commit_check`中被循环执行产生了大量的import进程 根据该方法的逻辑判断，里面的`continue`条件全都被绕过了，最终会去执行import 所以该问题出现的条件是： 1. db->count有存量未入库，且这个存量大于0条并小于MIN_COMMIT_COUNT 2. 当前indexd服务空闲，即MIN_COMMIT_TIME时长内没有接收到新的连接，这也符合凌晨用量少的特征 3. 迅搜的project较多（即代码里的user），因为我们的应用是多租户应用，我们为每个租户分配了一个project名，所以整体的project会比较多 当这三者条件同时存在时，此时是闲时，很多租户都仅有db->count少量的未入库数据时，就会启动很多import进行入库。不仅导致了内存占用大，也导致了很大的磁盘IO负载，两者都达到极限后，基本就爆了。。。 所以该如何解决？ 1. 无论是不是闲时，执行fork的场景都要限制一下import进程的数量，并且MAX_IMPORT_NUM是否考虑一下可以通过命令行选项自定义？ 2. 从客户端着手，将每个租户分配一个project的改成使用同一个？以减少project过多的情况？但万一真的有场景需要很多project的情况呢？所以对project数量的限制不太好 3. 从客户端着手，定时保持向迅搜发送index相关的请求，以免其处于闲时状态？但这做法是不是有点太临时了 所以综上所述，考虑并完善一下import进程数量的限制？