短信交互的上下文分析

如题,需求如下:
通过短信的菜单导航,用户在办理业务时,需要通过短信和服务器进行多次请求交互,如何维护用户的上下文?
短信的Session如何处理?

哪位牛人有类似的项目经验,可以分享一下,谢谢!
问题补充

hellojinjie 写道
memcached ?
将session 信息放入memcached,设定一个过期的时间。
取不到数据就说明没 session 了

话说你画的图中,整个查询都是无状态的,为啥要session


业务是一步一步交互,现在的需求是每个步骤的编码均是
01. xxx
02. xxx
这样,就需要在服务器端维护一个会话,来记录用户交互的上下文,
在真正处理具体业务时,需要从上下文中把操作的记录代码拼装起来,如 01 + 02 + 01 = 010201=最终的编码,
现在问题在于这些操作记录是否要放到session中维护?
问题补充
hellojinjie 写道
kingsfighter 写道
业务是一步一步交互,现在的需求是每个步骤的编码均是
01. xxx
02. xxx
这样,就需要在服务器端维护一个会话,来记录用户交互的上下文,
在真正处理具体业务时,需要从上下文中把操作的记录代码拼装起来,如 01 + 02 + 01 = 010201=最终的编码,
现在问题在于这些操作记录是否要放到session中维护?

可是你图片中的例子不是这样子的,把图片放这里不是误导大家吗

这样的需求当然要session了,可以把session放数据库里或者放到某种缓存中间件里。

不好意思,那是引用别人的图片……
我的初步想法是把session放到内存中,相当于放到缓存中,session 需要持久化到数据库中么?
持久化的目的是什么? 我也在衡量这两个方式的利弊。
谢谢。
问题补充
evanzzy 写道
LZ说的是OTA吧,这东西没什么前途,不搞也好

短信本身是无状态的,维持会话不太容易


不好意思,好像不是这个技术……
就是短信营业厅的使用,用短信交互来办理业务。
问题补充
ak478288 写道
手机号码就是sessionid,用个map保存信息吧。看情况是否要持久化到数据库。

正在看小丁的比赛,紧张啊,抽空说明一下,
我也是这样想的,但是不知道session是否要持久化到数据化? 有什么准则或者依据么?谢谢
问题补充
lydawen 写道
正好有smgp,sgip上下行相关经验。
首先短信是无状态的,另除了像一些什么活动会有所谓的上下文,如看名字好不好的。。。一步步引诱你。

像移动的短信菜单,都是固定的数字(唯一的),不存在很复杂的上下文。
数据保存到数据库比较好,记录下办理的是什么业务,记录到哪一步了。

你好,我也认为将上下文放到session里,但不确定session是否要持久化?操作记录是否要持久化?
目前唯一确定的是将最终办理业务的那个操作记录(01)持久化到数据库(如 01 - 02 -01 01是开通XX业务),但是操作记录…… 有的没有什么参考意义,是否有必要持久化到数据库?谢谢
问题补充
晨夕0599 写道
尽量避免在服务端保存短信的会话状态
可以使用子端口来代替
比如:用户发0到10086,你可以使用100861回复短信给用,提示他回复1到100861确认办法里

实在没办法才考虑保存用户的会话状态

你好,因为需求是要让用户操作的代码简单,就是将用户回复的代码都定义为 01,02,03 这样简短的编号,所以维护上下文应该是必要的,第二,回复100861不太符合需求,因为用户从头到尾都是回复到10086的……
谢谢
问题补充
lydawen 写道
正好有smgp,sgip上下行相关经验。
首先短信是无状态的,另除了像一些什么活动会有所谓的上下文,如看名字好不好的。。。一步步引诱你。

像移动的短信菜单,都是固定的数字(唯一的),不存在很复杂的上下文。
数据保存到数据库比较好,记录下办理的是什么业务,记录到哪一步了。

还请您把你的处理的具体方法分享出来,谢谢!
问题补充
vipyami 写道
怎么现在还在做短信营业厅?我们03年就上了,不知道现在还有人用没有,现在应该都普及宽带了吧?

额……  这个就不知道了,只负责前期的设计,可以简单描述下你们的概要设计结构不?谢谢
问题补充
vlinux 写道
session是必须要持久化的,否则如果全放在内存你的程序都不敢重启。

key是session+服务ID,尤其是你在用10086这种共用号码提供多种服务的时候,比如
回复1#1到10086进入订阅彩玲流程
回复2#1到10086进入订阅流量流程
这两个流程随着后续的交互可以做到让客户同时进行,所以session+服务ID是比较合理的

用户的回复可能会重复、甚至是无顺序的,所以用有限状态机的模式去处理
比如你期待用户回复的顺序是1#1 -> 1#2 -> 1#3 -> 完成
用户可能回复的顺序是:1#1 -> 1#1 -> 1#3
甚至可能试:1#3

专门开几个线程去处理会话超时的情况

当短信厅联不上mas的时候就别企图立即重试,进行延时稍候再次进行重试。注意处理好短信业务超时的关系。

谢谢你的回复,我好好思考一下
问题补充
coffeesweet 写道
场景:
用户第一次发“CX:用户号码”到10086,即第一次上行短信,当接受到该上行短信时
随机生成一串数字,比如84097,将其加到10086后面作为下行号码。
第一次下行短信回复“回复1#查询什么什么,回复2#查询什么什么...”;
这时1008684097就是该用户本次的sessionId,至于业务信息自己存来。

如果需求必须是“回复1#到10086查询什么什么,回复2#到10086查询什么什么”的话,就
想想其它办法吧,目前我们是类似按照前面说的这么干的。

目前的需求就是“回复1#到10086查询什么什么,回复2#到10086查询什么什么”,目的是让用户尽量少输入,提高用户体验,不过你说的这种思路挺好,可以跟领导沟通一下。
按你的思路,每个用户每一次操作都会建立一个下行号码?从而用户每次的回复号码都不一样?
再发散一下,能不能每次请求的一个业务建立一个下行号码?而不是每次请求都建立一个号码……
这样可以将不同业务隔离开,实现用户同时并行办理多个业务。
问题补充
sunnyfun 写道
保留会话可以采用
EJB的session bean
memcached
内存表
随便选一个,别放在web session里,依赖太大

应该会采用 memcached 或者 内存表 ,只保留在内存中不可靠,系统重启就什么都没有了……所以持久化应该是必要的
但是需要持久化哪些内容?
系统没有依赖web,只是想模拟web交互的过程(包括session),谢谢
查看全部
iteye_5073
iteye_5073
2011/05/04 14:13
  • 企业应用
  • 点赞
  • 收藏
  • 回答
    私信
满意答案
查看全部

0个回复