我可能错过了一个明显的平台差异,我应该适应但是我在尝试做时间格式时会得到这个(Python2.7)......
在Linux环境中:
>>> import time
>>> time.strftime("%a, %d-%b-%Y %T GMT", time.gmtime())
'Tue, 29-May-2012 21:42:04 GMT'
在Windows中:
>>> import time
>>> time.strftime("%a, %d-%b-%Y %T GMT", time.gmtime())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Invalid format string
从time.gmtime()返回的元组看起来是一样的,所以我不能完全确定我需要改变什么.
我发现后端消息处理中出现了常见的模式:
ServiceA生成大量消息.
ServiceB一次处理一条消息.
ServiceC发出对数据库或Web服务调用的调用,这可以通过批量调用获得显着的性能和可靠性.
在某些情况下,从ServiceA预批处理消息或在ServiceB中批量处理消息是不可行的,因此首选项将是单独处理所有消息,直到在ServiceC上进行最终调用.这需要在ServiceC调用之前进行批处理.
看似理想的情况是拥有一个NServiceBus处理程序签名,该签名可选择在批处理中传递消息,例如:
public void Handle(FooMessage[] messageBatch)
{
}
其中,在处理程序执行之前,messageBatch中的所有消息都不会被提交.
在NServiceBus中似乎没有本机支持.我可以在队列中一次处理消息并写入内存直到批量刷新.但在这种情况下,消息是在刷新之前提交的,如果进程崩溃,我们不会保留批处理中所有消息的传递保证.
所以问题是:由于某种原因我不会想到这是一个糟糕的模式吗？我知道知道何时刷新批次存在一个固有的问题,但似乎至少有一些传输实现缓冲了已经在引擎盖下的批处理中的消息,并且只是一次一个地交付.在这个级别进行批处理或者为定期刷新设置一个简单的超时似乎会起作用.
是否有解决方法或我缺少的首选模式？