发表于 | 分类于

由于业务需要，公司内部的ERP系统需要与小红书对接，介于odoo当前的市场覆盖率，apps store里自然是没有与此相关的现成模块可用了，既然没有现成的轮子可用，那么就只能自己造轮子了。

小红书接口

小红书的接口大部分都可以从小红书大学的开放平台上找到。这里我们主要的目的是将小红书的订单同步到我们本地的ERP系统中。

产品的匹配

小红书有自己的一套SKU编码，要与本地的ERP做映射关系，这样才能保证产品同步的一致性。这里我们使用了包装，跟ERP中的SKU做了一对一的映射。

小红书的物流模式

小红书支持多种物流模式，其中第三方保税模式是无法从系统中读取到订单状态的，只能利用小红书的回调接口将订单变化时推送到我们的系统中。所幸的是，我们目前的业务使用的一种是直邮，一种是小红书的保税仓(即RED STANDARD模式)。

用户信息

小红书对用户的隐私设置比较严格，只能获取到未发货的订单的用户信息，一旦订单发货，用户信息就变成了脱敏信息。

订单处理

小红书提供了两个与订单相关的接口，一个是批量查询接口，一个是查询某个订单的详细信息。因此我们的同步策略可以设置为先用批量查询接口同步批量订单信息，然后根据不同的订单状态筛选，针对那些没有完成的订单，定时轮询。

一旦订单有了发货时间，就将Odoo中的销售订单设置为确认状态，等订单完成，再自动将与之相关的出库单完成。

编码思路

小红书是一个平台，我们的店是其中的店铺，与接口相关的设置与店铺绑定，因此我们需要先创建店铺这个对象：

1
2
3
4
5
6
7
class account(models.Model):
    _name = "xiaohongshu.account"

    name = fields.Char("店铺名称")
    app_key = fields.Char("APP KEY", help="OPENAPI的key")
    app_secret = fields.Char("APP SECRET", help="OPENAPI的密钥")
    ...

appkey和appsecret是调用小红书开放平台的key和密钥。

然后我们使用odoo的定时任务，自动执行同步订单的操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@api.model
def _get_orders(self):
    """
    获取小红书的订单
    """
    shops = self.search([])
    for shop in shops:
        _logger.info(f"同步小红书店铺：{shop.name}的订单..")
        ark = ARK(shop.app_key, shop.app_secret)
        # 先同步待配货和配货中的订单
        # self._get_order_info(ark)
        # 再同步已发货的订单
        self._get_order_info(ark, status="shipped")
        # 已接收的订单
        self._get_order_info(ark, status="received")

为了与店铺的库位绑定，我们需要在店铺上指定销售的出库路线。

发表于 | 分类于

odoo中的用户类型

先从odoo中的用户类型说起，odoo中的用户大致可以分为三类：

  • 内部用户： 企业内部的用户，拥有对系统内部的访问权限，具体根据不同的角色权限不同而不同。
  • 门户用户： 非企业内部用户，通常为业务合作伙伴用户，拥有有限的资源访问权限。
  • 公共用户： 面向公众的权限，可以理解为游客权限。

在11.0及以前，门户和公共用户是在技术设置中的一个用户组，只要将某个用户放入到对应的组中即变为相应的用户类型。从12.0开始，用户类型由技术设置迁移到了更为明显的位置：

![demo.pngdeom.png)

技术应用

12.0 中此三个用户对应的用户组分别为

deom2

  • 内部用户：base.group_user
  • 门户用户：base.group_portal
  • 公共用户：base.group_public

发表于 | 分类于

安装 mysql和 redis

根据jumpserver要求 mysql>5.6 

1
2
3
sudo apt-get install mysql-server-5.7
sudo apt-get install libmysqlclient-dev
sudo apt-get install libsasl2-dev python-dev libldap2-dev libssl-dev

为了防止出现 error: command 'x86_64-linux-gnu-gcc' failed with exit status 1 错误，一般还要安装如下软件：

1
2
3
4
sudo apt-get install python3 python-dev python3-dev \
     build-essential libssl-dev libffi-dev \
     libxml2-dev libxslt1-dev zlib1g-dev \
     python-pip

在安装 python-gssapi时报了如下错误：

1
cffi.VerificationError: CompileError: command 'x86_64-linux-gnu-gcc' failed with exit status 1

需要安装依赖：

1
sudo apt-get install libkrb5-dev

下载源码

1
git clone --depth=1 https://github.com/jumpserver/jumpserver.git

安装依赖

1
2


碰到问题

Segmentation fault (core dumped)

解决：

ulimit -S -s unlimited

发表于 | 分类于

本步骤基于Ubuntu 18.04和 Postgresql 10.10 假设主数据库为 192.168.1.109 从数据库为192.168.1.111

主数据库配置

创建一个新目录

1
mkdir /var/lib/postgresql/10/main/pgarchive

创建流复制帐号

首先需要创建一个数据库用户进行主从同步。创建用户replica，并赋予登录和复制的权限

1
postgres# CREATE ROLE replica login replication encrypted password 'replica';

修改pg_hba.conf，允许replica用户同步

在pg_hba.conf里增加两行：

1
2
host     all             all          192.168.1.111/32          trust   #允许从服务器连接到主服务器
host   replication      replica       192.168.1.111/32          md5   #允许从服务器使用replica用户来复制

修改postgresql.conf

1
2
3
4
5
6
7
8
9
10
11
max_connections = 100 # 这个设置要注意下，从库的max_connections必须要大于主库的
max_wal_senders = 1   # 这个设置了可以最多有几个流复制连接，差不多有几个从，就设置几个 但是，还需要注意，pg_basebackup也会用到一个。
wal_level = replica 
archive_mode = on   # 设置自动归档
hot_standby = on 
archive_command = ‘test ! -f /var/lib/postgresql/10/main/pgarchive/%f && /usr/bin/rsync -a  %p /var/lib/postgresql/10/main/pgarchive/%f’ # 设置归档命令
wal_keep_segments = 128  # 设置流复制保留的最多的wal文件
full_page_writes = on # 开启全页写入 pg_rewind 前提条件 如果不将整个page写入WAL中，在介质恢复的时候WAL中记录的数据不足以实现完整的恢复
wal_log_hints = on # pg_rewind 前提条件
min_wal_size = 512MB #最小的wal 空间
max_wal_size = 2GB # max_wal_size = (3 * checkpoint_segments) * 16MB CheckPointSegments得到的值范围是 max_wal_size 的 1/3 ～ 1/2，最小为1

修改完 ，重启主数据库

在测试服务器上测试是否能够正常连接：

1
psql -h 192.168.1.109 -U postgres

从服务器

从主服务器拷贝基础数据

首先需要删除从数据库下所有数据：

1
pg_basebackup -h 192.168.1.109 -U replica -F p -X stream -P -R -D /var/lib/postgresql/10/main/

pg_basebackup参数说明如下：

  • -h: 指定连接的数据库的主机名或IP地址
  • -U: 指定连接的用户名
  • -F: 指定了输出的格式，支持p（原样输出）或者t（tar格式输出）
  • -X: 表示备份开始后，启动另一个流复制连接从主库接收WAL日志
  • -P: 表示允许在备份过程中实时的打印备份的进度
  • -R: 表示会在备份结束后自动生成recovery.conf文件
  • -D: 指定备份写入的数据目录,需要与数据库配置的数据库目录一致,初次备份之前从库的数据目录需要手动清空
  • -l: 表示指定一个备份的标识

配置从库recovery.conf

修改recovery.conf 如下内容：

1
2
3
4
5
6
standby_mode = 'on'
primary_conninfo = 'user=replica password=123456 host=db1 port=5432 sslmode=disable sslcompression=1 target_session_attrs=any'
restore_command = '/usr/bin/rsync -a  %f /var/lib/postgresql/10/main/pgarchive%p'
# recovery_target_timeline = 'latest' #测试采用默认即可
archive_cleanup_command = 'pg_archivecleanup /var/lib/postgresql/10/main/pgarchive %r'
recovery_target_timeline = 'latest' # 一定要配置这个，要不然主从切换后不会同步成功

然后重启从服务器

查看同步状态

主库查询

1
select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;

查询备库落后多少字节

1
select client_addr, pg_wal_lsn_diff(sent_lsn,replay_lsn)/1024/1024 as MB from pg_stat_replication;

发表于 | 分类于

odoo在开启多worker时，如果nginx没有配置/longpull，会报如下错误：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
web.assets_common.js:3556 Server application error
 Error code: 200 
 Error message: Odoo Server Error 
 Error data message:
 bus.Bus unavailable 
 Error data debug:
 Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/http.py", line 656, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  File "/usr/lib/python3/dist-packages/odoo/http.py", line 314, in _handle_exception
    raise pycompat.reraise(type(exception), exception, sys.exc_info()[2])
  File "/usr/lib/python3/dist-packages/odoo/tools/pycompat.py", line 87, in reraise
    raise value
  File "/usr/lib/python3/dist-packages/odoo/http.py", line 698, in dispatch
    result = self._call_function(**self.params)
  File "/usr/lib/python3/dist-packages/odoo/http.py", line 346, in _call_function
    return checked_call(self.db, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/odoo/service/model.py", line 97, in wrapper
    return f(dbname, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/odoo/http.py", line 339, in checked_call
    result = self.endpoint(*a, **kw)
  File "/usr/lib/python3/dist-packages/odoo/http.py", line 941, in __call__
    return self.method(*args, **kw)
  File "/usr/lib/python3/dist-packages/odoo/http.py", line 519, in response_wrap
    response = f(*args, **kw)
  File "/usr/lib/python3/dist-packages/odoo/addons/bus/controllers/main.py", line 37, in poll
    raise Exception("bus.Bus unavailable")
Exception: bus.Bus unavailable

解决方案就是在nginx中添加：

1
2
3
4
5
6
location /longpolling/ {  
    proxy_pass        http://127.0.0.1:8072/longpolling/;  
    proxy_redirect    off;  
    proxy_set_header  X-Real-IP        $remote_addr;  
    proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;  
}

发表于 | 分类于

由于经常在多个odoo环境中切换开发，不可避免的会碰到数据库版本不一致的问题，解决的方案是给每个版本指定一个数据库用户，从而做到数据库分离。 因为某种原因，给数据库用户更换了名称，以前可以正常使用的数据库不能用了，报的错误如下：

1
2
3
4
5
6
7
8
9
10
11
12
    response = f(*args, **kw)
  File "/mnt/hgfs/Code/odoo-11.0/odoo-11.0/addons/web/controllers/main.py", line 684, in selector
    return self._render_template(manage=False)
  File "/mnt/hgfs/Code/odoo-11.0/odoo-11.0/addons/web/controllers/main.py", line 674, in _render_template
    d['incompatible_databases'] = odoo.service.db.list_db_incompatible(d['databases'])
  File "/mnt/hgfs/Code/odoo-11.0/odoo-11.0/odoo/service/db.py", line 400, in list_db_incompatible
    cr.execute("SELECT latest_version FROM ir_module_module WHERE name=%s", ('base',))
  File "/mnt/hgfs/Code/odoo-11.0/odoo-11.0/odoo/sql_db.py", line 155, in wrapper
    return f(self, *args, **kwargs)
  File "/mnt/hgfs/Code/odoo-11.0/odoo-11.0/odoo/sql_db.py", line 232, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.InsufficientPrivilege: permission denied for relation ir_module_module

因为之前已经把数据库的owner从老用户转到了新用户头上，因此不是数据库的owner不对造成的。使用\dt命令查看，发现，虽然数据库改过来了，而该数据库下的表的owner还是老用户。

由于表、视图等数量很多，不能一一更改，因此我们需要找到一个快捷的方法。

1
reassign owned by old_name to new_name;

不过该方法有个副作用，如果你的old_name拥有多个数据库，那么哪些数据库也同样会被修改到新用户名下。

发表于 | 分类于

前段时间，我们对接了支付宝，这次我们来对接微信支付。

沙箱环境

微信支付没有沙箱环境，要想测试就必须有营业执照。

Python SDK

这里我们使用的是开源SDK库 WechatPy

微信支付

要使用微信支付，你必须要满足一下条件

  • APPID: 一个绑定了微信支付的公众号APPID
  • API KEY: 在申请微信支付后可以设置，用于调用微信接口
  • 商户号： 开通了微信支付的商户编号
  • 商户证书文件： 开通了微信支付的商户证书
  • 商户密钥文件： 跟商户证书匹配的密钥文件

有了这几个参数才可以正确的调用微信支付的接口

1
2
3
4
5
6
7
8
9
10
11
12
def _get_wechatpay(self):
    """获取微信支付客户端"""
    try:
        # WeChatPay has no sandbox enviroment.
        wechatpay = WeChatPay(self.wechatpay_appid,
                                self.wechatpay_app_key,
                                self.wechatpay_mch_id,
                                mch_cert=self.wechatpay_mch_cert,
                                mch_key=self.wechatpay_mch_key)
        return wechatpay
    except Exception as err:
        _logger.exception(f"生成微信支付客户端失败:{err}")

odoo的官方商城支付，对应的微信支付是Navtive方式。

微信与支付不同的是，官方并没有给我们提供一个收银台页面，因此，我们需要自己实现一个，并持续监听，等到客户付款完成后再跳转验证页面。

微信的验证也是两种方式，一种是微信官方的推送消息，一种是我们自己根据订单去微信支付服务器查询。(这点不同于支付宝)。

主动查询

主动查询，用到的是wechatpy的query接口，查询起来比较简单：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
@api.model
def wechatpy_query_pay(self, order):
    """
    主动去微信支付查询支付结果
    用户支付前没有transcation_id因此，只能用商户自有订单号去查
    只有SUCCESS支付成功，其他状态均不成功
    """
    wechatpay = self._get_wechatpay()
    res = wechatpay.order.query(out_trade_no=order)
    _logger.info("主动查询微信支付结果:{}".format(res))
    if res["return_code"] == "SUCCESS" and res["result_code"] == "SUCCESS":
        if res["trade_state"] == "SUCCESS":
            transaction = self.env["payment.transaction"].sudo().search(
                [('reference', '=', order)], limit=1)
            if transaction.state in ('draft', 'pending', 'authorized'):
                # 将支付结果设置完成
                result = {
                    "acquirer_reference": res['transaction_id']
                }
                transaction.write(result)
                transaction._set_transaction_done()
                return True
            elif transaction.state == 'done':
                return True
            else:
                return False
    return False

需要说明的是，我们再验证了支付之后，需要将对应的支付事务完成。

微信消息处理

客户在支付完成后，微信官方会给我们传入的回调地址发送业务通知。这点wechatpy也帮我们封装好了方法，使用起来也很方便：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
def _verify_wechatpay(self, data):
    """验证微信支付服务器返回的信息"""
    try:
        wechatpay = self._get_wechatpay()
        result = wechatpay.parse_payment_result(data)
        _logger.info("解析微信支付返回结果：{}".format(result))
        if result['result_code'] == 'SUCCESS' and result['return_code'] == 'SUCCESS':
            # 支付校验成功
            transaction = self.env["payment.transaction"].sudo().search(
                [('reference', '=', result["out_trade_no"])], limit=1)
            if transaction.state in ('draft', 'pending', 'authorized'):
                # 将支付结果设置完成
                result = {
                    "acquirer_reference": result['transaction_id']
                }
                transaction.write(result)
                transaction._set_transaction_done()
                return True
            elif transaction.state == 'done':
                return True
            else:
                return False
        return False
    except Exception as err:
        _logger.error("解析微信支付推送消息失败:{}".format(traceback.format_exc()))
        return False

在验证了微信的消息之后，同样也要将支付事务设置为完成状态。

完整示例

模块开源，下载地址

发表于 | 分类于

没想到过了这么多年，odoo的邮箱配置还是如此的骨骼清奇。总结一下，最近用到的配置方法：

配置收件箱接收邮件

下面以国内常见的企业邮箱服务为例，比如阿里企业邮，腾讯企业邮，来介绍一下配置步骤。

首先在技术-邮件-收件箱服务器中创建一个邮箱。

这里推荐使用IMAP协议，可以在邮件服务器上保存一份已读邮件的备份。

如果用户名和密码配置正确，点击测试确认按钮，将收件服务器的状态变为确认状态。

配置外部邮箱别名

一般设置为公司的邮箱后缀：

配置别名

odoo的邮件分发策略是根据系统中的别名来实现的，如果你只是配置了邮件服务器而没有配置别名，odoo在收取邮件的时候就会告诉你：

1
ValueError: No possible route found for incoming message from <microsoft@outlook-address.com> to "'Administrator'" <my_address@gmail.com> (Message-Id <000f01d39516$e032a170$a097e450$@outlook-address.com>:). Create an appropriate mail.alias or force the destination model.

意思就是你必须配置一个别名来匹配你的收件箱服务器，配置别名的地方有很多，像团队，用户和设置中都有配置别名的地方。我们这里选择在用户界面上配置，然后将邮件消息显示到合作伙伴的chatter中：

Alias Model指的是将邮件消息绑定的对象模型，我们这里选择的是res.partner，记录ID就是我们用户对应的partner_id。

配置完别名 就可以测试接收邮件了。

接收到邮箱的动作

之所以选择合作伙伴，是因为我们想要实现一种当收到邮箱之后，自动分析邮件中的附件的操作(附件是一种csv文件，需要将其中的部分数据自动更新到已有的产品中去)。

从mail.thread的源码的注释来看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
mail_thread model is meant to be inherited by any model that needs to
act as a discussion topic on which messages can be attached. Public
methods are prefixed with ``message_`` in order to avoid name
collisions with methods of the models that will inherit from this class.

``mail.thread`` defines fields used to handle and display the
communication history. ``mail.thread`` also manages followers of
inheriting classes. All features and expected behavior are managed
by mail.thread. Widgets has been designed for the 7.0 and following
versions of Odoo.

Inheriting classes are not required to implement any method, as the
default implementation will work for any model. However it is common
to override at least the ``message_new`` and ``message_update``
methods (calling ``super``) to add model-specific behavior at
creation and update of a thread when processing incoming emails.

已经告诉了我们方法，在需要创建/更新的模型上定义message_new和message_update方法就可以实现我们想要的效果(阅读源码，好处多多呀)。因为我们的联系人已经创建了，因此，这里使用的是message_update方法:

1
2
3
4
5
6
class res_partner(models.Model):
    _inherit = "res.partner"

    @api.multi
    def message_update(self, msg_dict, update_vals=None):
        pass

msg_dict是包含邮件消息的字典
update_vals是需要更新记录的值

发表于 | 分类于

两行命令搞定

1
2
3
$ rabbitmqadmin -f tsv -q list queues name > q.txt

$ while read -r name; do rabbitmqadmin -q delete queue name="${name}"; done < q.txt

如果出现了权限问题，则需要指定host 和用户名密码

1
rabbitmqadmin --host=localhost -u xxxxx -p xxxxx -f tsv -q list queues name > q.txt

参考原文

发表于 | 分类于

odoo本身支持多数据库还是挺方便的，再没有开启多worker的情况下，感觉还不错。随着业务量的增长，我们势必会要开启多核以发挥最大化的性能。然而，odoo的多核模式却还隐藏着若干个坑，现在我们要提到的就是多数据库模式的坑。

问题的起源

之前讲到过，我们的系统需要跟其他的系统进行对接，为了解耦，消息队列就成了一个必然的选择。在我们搭建对接完成之后，服务跑的还可以，以为万事大吉，可以不用再过多过问消息对队列的问题了。然而没想到的事，有一天有人说两个系统之间的数据不一致，根据日志发现，跑的好好的RabbitMQ，突然就断开了。具体的表现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
2019-11-19 06:53:11,381 10002 INFO ? odoo.sql_db: ConnectionPool(used=0/count=0/max=64): Closed 4 connections to 'user=odoo password=xxx dbname=erp host=172.19.0.12 port=5432 sslmode=prefer' 
2019-11-19 06:53:11,399 10002 INFO ? odoo.sql_db: ConnectionPool(used=0/count=0/max=64): Closed 1 connections to 'user=odoo password=xxx dbname=erp-dev host=172.19.0.12 port=5432 sslmode=prefer' 
2019-11-19 06:53:11,417 10002 INFO ? odoo.sql_db: ConnectionPool(used=0/count=0/max=64): Closed 1 connections to 'user=odoo password=xxx dbname=odoo host=172.19.0.12 port=5432 sslmode=prefer' 
2019-11-19 06:53:11,434 10002 INFO ? odoo.sql_db: ConnectionPool(used=0/count=0/max=64): Closed 1 connections to 'user=odoo password=xxx dbname=demo host=172.19.0.12 port=5432 sslmode=prefer' 
2019-11-19 06:53:16,247 10003 INFO erp odoo.addons.base.models.ir_cron: Starting job `Backup scheduler`. 
2019-11-19 06:53:16,273 10003 INFO erp odoo.modules.registry: Invalidating all model caches after database signaling. 
2019-11-19 06:53:16,280 10003 ERROR erp odoo.addons.base.models.ir_cron: Call from cron Backup scheduler for server action #762 failed in Job #24 
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/addons/base/models/ir_cron.py", line 102, in _callback
--
ERROR: cursor already closed 
2019-11-19 06:55:21,297 10002 INFO ? odoo.sql_db: ConnectionPool(used=0/count=0/max=64): Closed 5 connections to 'user=odoo password=xxx dbname=erp host=172.19.0.12 port=5432 sslmode=prefer' 
2019-11-19 06:55:21,307 10002 ERROR erp odoo.addons.orssica_erp.models.consumer: Traceback (most recent call last):
  File "/home/ubuntu/odoo/odoo-dev/custom/he_addons/orssica_erp/models/consumer.py", line 127, in handler_output
    picking = picking_obj.create(picking_data)
  File "<decorator-gen-394>", line 2, in create
  File "/usr/lib/python3/dist-packages/odoo/api.py", line 430, in _model_create_single
    return create(self, arg)
  File "/home/ubuntu/odoo/odoo-dev/custom/he_addons/pos_retail/models/stock/stock_picking.py", line 15, in create
    picking = super(stock_picking, self).create(vals)
  File "<decorator-gen-194>", line 2, in create
--
psycopg2.InterfaceError: cursor already closed

从日志上分析，是原本在接收到消息之后要执行的后续动作因为数据库连接的关闭而被阻断了。为了查找连接被阻断的原因，我们查看了odoo相关的配置：

1
2
3
4
5
6
7
limit_time_cpu = 7200
limit_time_real = 7200
; limit_request = 200
workers = 4 
limit_memory_hard = 1610612736
limit_memory_soft = 4294967296  
; list_db = False

最开始以为是多核模式下的内存设置问题，后来经过几次调整，发现问题并未得到改善。显然也不是因为CPU时间问题，因为如果时CPU时间超时的错误提示并非直接关闭数据库。

源码分析

在几经搜索无果之后，只能去源码里一探究竟了。我们发现，报错之前总是伴随着数据库连接关闭。而数据库连接关闭的日志是INFO，显然这是odoo的主动行为而并非意外关闭。根据提示，我们定位到sql_db.py文件的相关代码：

1
2
3
4
5
6
7
8
9
10
11
@locked
def close_all(self, dsn=None):
    count = 0
    last = None
    for i, (cnx, used) in tools.reverse_enumerate(self._connections):
        if dsn is None or cnx._original_dsn == dsn:
            cnx.close()
            last = self._connections.pop(i)[0]
            count += 1
    _logger.info('%r: Closed %d connections %s', self, count,
                (dsn and last and 'to %r' % last.dsn) or '')

然后顺藤摸瓜地找到了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
def process_work(self):
    rpc_request = logging.getLogger('odoo.netsvc.rpc.request')
    rpc_request_flag = rpc_request.isEnabledFor(logging.DEBUG)
    _logger.debug("WorkerCron (%s) polling for jobs", self.pid)
    db_names = self._db_list()
    if len(db_names):
        self.db_index = (self.db_index + 1) % len(db_names)
        db_name = db_names[self.db_index]
        self.setproctitle(db_name)
        if rpc_request_flag:
            start_time = time.time()
            start_memory = memory_info(psutil.Process(os.getpid()))

        from odoo.addons import base
        base.models.ir_cron.ir_cron._acquire_job(db_name)

        # dont keep cursors in multi database mode
        if len(db_names) > 1:
            odoo.sql_db.close_db(db_name)
        if rpc_request_flag:
            run_time = time.time() - start_time
            end_memory = memory_info(psutil.Process(os.getpid()))
            vms_diff = (end_memory - start_memory) / 1024
            logline = '%s time:%.3fs mem: %sk -> %sk (diff: %sk)' % \
                (db_name, run_time, start_memory / 1024, end_memory / 1024, vms_diff)
            _logger.debug("WorkerCron (%s) %s", self.pid, logline)

        self.request_count += 1
        if self.request_count >= self.request_max and self.request_max < len(db_names):
            _logger.error("There are more dabatases to process than allowed "
                            "by the `limit_request` configuration variable: %s more.",
                            len(db_names) - self.request_max)
    else:
        self.db_index = 0

从这段代码上来看，当odoo发现你是多数据库模式，新开一个worker的时候就会把之前的worker的数据库连接关掉。这就是造成，我们之前的数据库连接被莫名其妙干掉的原因。

知道了原因，解决方案就浮出水面了。既然多数据库模式下会出现这个问题，那么我们就把多余的数据库干掉就好了。

经验与教训

多数据库模式下，新开worker会关闭所有数据库连接。因此，我们在生产环境中最好不要建里多个数据库，如果要，也要用多个postgresql的用户使之独立，再结合odoo的db_filter参数，确保_db_list方法获取到的数据库只有一个就能避免这个问题。