3

我在一家软件商店工作,该商店有一个内部预测拨号器产品,我们需要实现一个遵从DO-NOT-CALL列表的解决方案。什么是高可用性授权服务的正确解决方案?

基本上,我有一个客户/潜在客户的数据库,我需要拨打电话,另一个数据库的电话号码我无法拨打。由于该系统是预测拨号器,基于操作性能,时间平均值和内容,它会为每个记录的系统用户拨打更多或更少的呼叫。通常这个“魔术”号码是每个记录的代理大约3-4次呼叫。

预测拨号程序的电话号码存储库是PostgreSQL数据库。预测拨号程序从数据库中挑选一堆数字,并向pbx发送一个命令以拨打该群,然后业务逻辑继续将有效呼叫转移到呼叫中心职员等等(这与我无关问题在通话之前)。

我需要实现拒收电话列表功能。政府机构每天都会以CSV文件的形式向本公司提供拒收电话清单。每次我收到一个新的CSV文件时,我都必须清除旧的拒收电话清单,然后放入新的电话清单。

我首先想到的是实现批处理,将DO NOT CALL LIST与我当前的客户数据库交叉引用。但我认为,根据两个数据库的大小,交叉引用会非常耗费性能,有时无法在一夜之间完成。以前我在批处理时遇到过这种问题,看起来不是件好事。

当我想到大型机构如何处理高性能和高吞吐量的授权系统(如信用卡或用户认证/授权)时,我提出了第二个想法。我认为创建DO NOT CALL LIST号码的身份验证服务,以及在拨号之前更改我的预测拨号程序的算法以检查每个号码与此授权服务之间的关系是很简单的。

由于我只是在这里讨论,所以我不知道哪个想法是最好的,或者如果我完全错误并且应该朝另一个方向发展。所以,我的问题是:你的建议是什么?将DO NOT CALL CSV文件存储在内存中?使用LDAP?使用MySQL? PostgreSQL的?做批处理的事情?还是我肯定搞砸了?

我知道我不是世界上第一个有这种问题的人,所以请赐教。

回答

2

您的挑战,从可能条目的广阔空间中查找大量条目,让我想起DNS black/block lists

rbldnsd是一个小而快速的DNS 守护进程特别作出 服务DNSBL区。这个守护进程是由djbdns包中Dan J.Bernstein的rbldns 程序启发的 。 More rbldnsd, from Google

它基于域名的区域的支持,所以你可以转换数字来ENUM式的URI列表 - 例如,+ 1-555-4242变得2.4.2.4.5.5.5.1.e164.arpa。然后将其输入到rbldnsd数据文件中,并将其编译到内存中并像其他任何阻塞列表一样进行访问。默认条目意味着可以打电话,或者如果条目存在,它将被给予DoNotCall条目。

尽管它的脚本稍微简单一些,但仍然可能会遇到批处理转换问题,但可能会使用Perl或AWK。您也可以将传入的CSV文件分割为多个文件进行并行处理,并进行最终合并。

相关问题