短信交互的上下文分析
如题，需求如下：
通过短信的菜单导航，用户在办理业务时，需要通过短信和服务器进行多次请求交互，如何维护用户的上下文？
短信的Session如何处理？
哪位牛人有类似的项目经验，可以分享一下，谢谢！
问题补充
hellojinjie 写道
memcached ?
将session 信息放入memcached，设定一个过期的时间。
取不到数据就说明没 session 了
话说你画的图中，整个查询都是无状态的，为啥要session
将session 信息放入memcached，设定一个过期的时间。
取不到数据就说明没 session 了
话说你画的图中，整个查询都是无状态的，为啥要session
业务是一步一步交互，现在的需求是每个步骤的编码均是
01. xxx
02. xxx
这样，就需要在服务器端维护一个会话，来记录用户交互的上下文，
在真正处理具体业务时，需要从上下文中把操作的记录代码拼装起来，如 01 + 02 + 01 = 010201=最终的编码，
现在问题在于这些操作记录是否要放到session中维护？
问题补充
hellojinjie 写道
kingsfighter 写道
业务是一步一步交互，现在的需求是每个步骤的编码均是
01. xxx
02. xxx
这样，就需要在服务器端维护一个会话，来记录用户交互的上下文，
在真正处理具体业务时，需要从上下文中把操作的记录代码拼装起来，如 01 + 02 + 01 = 010201=最终的编码，
现在问题在于这些操作记录是否要放到session中维护？
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确认办法里
实在没办法才考虑保存用户的会话状态
可以使用子端口来代替
比如：用户发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的时候就别企图立即重试，进行延时稍候再次进行重试。注意处理好短信业务超时的关系。
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查询什么什么”的话，就
想想其它办法吧，目前我们是类似按照前面说的这么干的。
用户第一次发“CX:用户号码”到10086，即第一次上行短信，当接受到该上行短信时
随机生成一串数字，比如84097，将其加到10086后面作为下行号码。
第一次下行短信回复“回复1#查询什么什么,回复2#查询什么什么...”；
这时1008684097就是该用户本次的sessionId,至于业务信息自己存来。
如果需求必须是“回复1#到10086查询什么什么,回复2#到10086查询什么什么”的话，就
想想其它办法吧，目前我们是类似按照前面说的这么干的。
目前的需求就是“回复1#到10086查询什么什么,回复2#到10086查询什么什么”，目的是让用户尽量少输入，提高用户体验，不过你说的这种思路挺好，可以跟领导沟通一下。
按你的思路，每个用户每一次操作都会建立一个下行号码？从而用户每次的回复号码都不一样？
再发散一下，能不能每次请求的一个业务建立一个下行号码？而不是每次请求都建立一个号码……
这样可以将不同业务隔离开，实现用户同时并行办理多个业务。
问题补充
sunnyfun 写道
保留会话可以采用
EJB的session bean
memcached
内存表
随便选一个，别放在web session里，依赖太大
EJB的session bean
memcached
内存表
随便选一个，别放在web session里，依赖太大
应该会采用 memcached 或者 内存表 ，只保留在内存中不可靠，系统重启就什么都没有了……所以持久化应该是必要的
但是需要持久化哪些内容？
系统没有依赖web，只是想模拟web交互的过程（包括session），谢谢
iteye_5073
2011/05/04 14:13- 企业应用
- 点赞
- 收藏
- 回答
满意答案